近些年來非常火爆的微服務架構，曾經讓我以前團隊（某團**後台組）從泥沼中脫身出來，輕鬆的應對線上大量的業務壓力，而如今卻讓我現在的團隊深入泥沼中。
12年剛來某團**後台組的時候，只有乙個專案groupapi。只有4個rd因對c端版本迭代的開發，從3.5版本每日訪問量1kw。後來隨著業務隊伍的擴大，乙個專案逐漸拆成10個專案（推薦，push，廣告...）。再後來隨著日訪問量的增加，**內部開始拆分成不同的微小服務（groupdeal，sinai（poi查詢），sieve（deal，poi檢索），groupgeo...）。但是很明顯的乙個感受就是casestudy比上個季度少了很多。通過微服務，每個小團隊都只需要全心關注自己的乙個比較純粹，比較單一的服務。這樣單個服務的可用效能可以提高到好幾個個9。通過分層的架構能保證每次業務迭代，上線流程都非常清晰簡單。通常情況一般上線都只牽涉到一到兩個服務。上線步驟也比較簡單，同時能平滑發布，回滾。
下面稍微總結下微服務架構帶來的好處：
每個小組專注於乙個微型服務，致力於該服務的穩定性，可用性，服務效能，以及業務的迭代開發
通過分層的架構模式，讓發布流程簡單，平滑發布回滾
整體上事故次數減少，每次事故影響範圍減少
因為**後台有統一的api接入層，並且有穩定的團隊在負責，所以與c端同學的對接比較順暢。與c端對接包含高質量的介面文件，設計良好的url，低bug的介面開發，規定時間內開發，聯調完畢。因為有統一的api接入層，所以與c端同學打交道很舒暢，大家都很幸福
換到乙個新的專案組後，真心體會到很多重要原則沒有把握好會把微服務架構玩壞。先把情況簡單介紹下：
新團隊不是採用演進的方式進行微服務，而是按照職能切分成幾大塊。幾大塊之間並沒有分層設計，還是網狀堆砌起來（很明顯的乙個問題就是相互依賴）。同時個大塊之間並沒有實現不該關心邏輯的透明化。簡單講就是乙個服務其實對外應該是黑盒。內部的結構，內部獨有的邏輯應該對外部服務透明，不應該還對外暴漏。但是現實的情況是服務對外並沒有實現很好的封裝。
舉例說明：supplier專案相當於與第三方**商對接的閘道器。supplier需要維護與每個第三方**商的許可權，認證，服務code，手藝人code。但是出乎意料的是supplier居然把魚第三方互動的code，流露到了別的服務系統。本應該是其獨有與第三方互動的邏輯，資訊卻需要別的服務關心，沒有做到透明的封裝。
服務究竟應該如何的劃分才更加合理？這個問題我想了很多，其實難以給出乙個標準的答案。但是從實踐來看，確實有一些線索可以追尋的。回到上面的groupapi的演進來看，有乙個準則：唯一權責原則。如果你的服務中涉及到做了多個事情，意思是沒有做到唯一權責原則，那麼就可以將其中的一部分抽取出去，單獨維護。其實這裡強調了乙個演進的過程。我覺得微服務化更多是乙個演進的步驟，而非自上向下的生硬劃分。
微型服務劃分大小確實會給工程帶來不同的bug密度，下面一張圖來自《unix程式設計藝術》，將的是模組劃分的粒度與bug密度的關係。從巨集觀角度來看，微型服務與模組有本質上的相同。下面圖形中，看到bug密度
微服務架構切記：
乙個單獨的微型服務，盡量保證純粹，良好的封裝性。良好的封裝表示不會對外暴露自身的細節。
微型服務的組織盡量保證有一定的層次性，不要胡亂的或者網狀的組織微型服務，不要出現胡亂依賴，迴圈依賴。
微型服務切記不要劃分的太細，也不要劃分的太粗。具體那個度適中，這個需要根據具體的case進行思考
每個微型服務都應該時刻驚醒===>自己依賴的服務。每個這些外部服務的健康狀況都會對你的服務產生直接影響。同時你要經常梳理自己的服務的依賴，如果不是真正的必要，不要引入別的服務的依賴
微服務架構思考
二 從迭代的角度去考慮 服務拆分的缺點 1.每個服務都需要單獨的機器部署，浪費資源,增加運維負擔 2.服務拆分後會產生分布式事務 跨庫事務 跨庫分頁 3.服務較多時，服務之間的依賴關係複雜，不好治理 4.拆分後不便於排查問題，不便於debug 5.特殊業務的服務歸屬問題難以決定，當乙個介面即可以放在...
企業架構思考
roger sessions是objectwatch的cto。在紐西蘭teched2009的session arc203 services and complexity 分享了自己關於企業架構的獨特觀點，非常令人印象深刻，無疑可以給大家帶來很多思考。roger認為ea企業架構可以實現的所謂 立即的 ...
程式架構思考
可以將程式分為3部分，乙個是邏輯 logic 乙個是控制 control 資料結構 data structures 邏輯是用來解決實際問題的，也就是具體問題的實現。控制是將多個邏輯組合起來工作的方式，即邏輯組合的策略。資料結構是計算機中儲存 組織資料的方式。程式執行的效率取決於這三者的組合結果。如果...