為應對如今無線優先和全渠道使用者體驗的需求和挑戰，我們該如何設計靈活的面向體驗的微服務架構？它有哪些模式和最佳實踐？攜程，Netflix和SoundCloud這些知名網際網路公司是如何實踐面向體驗的微服務架構的？在過去的2015年，大牛馬丁福勒對微服務有哪些新的觀點？

背景介紹

2007-2012年，我曾經就職於億貝中國研發中心（eBay CDC）的開放API平臺部門，親歷了當時世界第一大C2C電商平臺的服務化和API化的過程，億貝的經歷讓我對服務化和API這個技術領域產生了濃厚的興趣；2013-2014年，我就職於攜程旅遊網框架研發部，有幸主導了攜程服務化體系和無線API閘道器的建設，本分享基於我之前的實戰經驗，以及自己近期在業餘時間對業界服務化最新進展的學習、思考和總結。

微服務各家玩法不盡相同，我發現一些術語的叫法各公司也是不同的，可以說微服務目前仍在激烈的演化中，這個領域還未成熟和標準化，所以今天的分享主要是我個人的視角和總結，目的是拋磚引玉，激發大家進一步探索和實踐。

本次分享的主題包括：

1. 微服務架構原理

2. 使用者體驗適配層（Backend For Frontend）

3. 攜程無線微服務案例分享

4. Netflix微服務架構分析

5. SoundCloud微服務架構分析

6. 微服務架構不是免費的午餐

7. 總結

本次分享也是應聊聊架構群內一些朋友的要求，將之前零散分享的內容總結成文，本次分享過程中會貼出相關內容參考連結（其中有些來自SlideShare和Netflix techblog的連結需國內或許不能訪問訪問），供有興趣的朋友進一步學習。

一、微服務架構原理

微服務是個新概念，但它沒有一個明確的定義，各家對微服務的描述不盡相同，本人更傾向於用一些架構原理來描述它，因為架構原理是相對抽象和穩定的，而具體實現可以千差萬別。微服務原理和軟體工程，面向物件設計中的基本原理相通，體現如下：

1. 單一職責（Single Responsibility），一個服務應當承擔儘可能單一的職責，服務應基於有界的上下文（bounded context，通常是邊界清晰的業務領域）構建，服務理想應當只有一個變更的理由（類似Robert C. Martin講的：A class should have only one reason to change），當一個服務承擔過多職責，就會產生各種耦合性

   問題，需要進一步拆分使其儘可能職責單一化。

2. 關注分離（Separation of Concerns），跨橫切面邏輯，例如日誌分析、監控、限流、安全等等，儘可能與具體的業務邏輯相互分離，讓開發人員能專注於業務邏輯的開發，減輕他們的思考負擔，這個也是有界上下文（bounded context）的一個體現。

3. 模組化（Modularity）和分而治之（Divide & Conquer），這個是解決複雜性問題的一般性方法，將大問題（如單塊架構）大而化小（模組化和微服務化），然後分而治之。

微服務架構同時還是一個組織原理的體現，這個原理就是康威定律（Conway’s Law），Melvin Conway在1968年指出：“Any organization that design a system(defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”，翻譯成中文就是：設計系統的組織，其產生的設計和架構等價於組織間的溝通結構。Dan North對此還補充說：“Those system then constrain the options for organization change”，簡言之，這些系統在建成之後反過來還會約束和限制組織的改變。下面兩個圖進一步解釋了這一組織原理：

Fig 1，團隊結構和系統架構不匹配

一般企業剛起步時，業務規模小，開發團隊規模也小，所以通常開發出來的系統是單塊的；隨著業務的擴大，團隊規模也會隨之擴大，這個時候多團隊組織架構和單塊系統架構之間就會產生不匹配問題（溝通協調成本增加，交付效率低下等等），如果不對單塊架構進行解耦和調整以適應新的團隊溝通結構，就會制約組織生產力和創新速度。

Fig 2，團隊結構和系統架構匹配

把單塊架構按照業務和團隊邊界進行拆分，重新調整為模組化分散式架構（微服務架構是一種方案），那麼組織團隊溝通結構和系統架構之間又能匹配起來，各個團隊才能夠獨立自治地演化各自的子系統（微服務），這種架構的解耦和調整可以解放組織生產力和提升創新速度。

 

二、使用者體驗適配層（Backend For Frontend）

眾所周知，隨著無線技術的發展和各種智慧裝置的興起，網際網路應用已經從單一Web瀏覽器時代演進到以API驅動的無線優先（Mobile First）和面向全渠道體驗（omni-channel experience oriented）的時代，如下圖所示：

Fig 3，從單一網站到API驅動的全渠道體驗

應用架構的新挑戰是：

1. 使用者接入形式的多樣性，無線（手機、Pad），Web，網際網路電視，第三方合作應用等等，各種使用者裝置的螢幕大小，操控體驗方式各不相同，例如，手機裝置的螢幕較小，能夠展示的資料量小，互動方式以觸控為主，也可通過條形碼掃描器；

2. 有些使用者裝置的頻寬受限，同時應用的UI一般宿主在客戶端，有些頁面需要組合好幾個後臺業務服務的資料和功能，如果直接在客戶端發起對多個後臺服務的呼叫，勢必造成大量網路開銷影響效能，這個有點類似資料庫查詢中的n+1問題。

BFF（Backend For Frontend）是應對上述應用架構挑戰的一種模式和最佳實踐，2015年底，ThoughtWorks在其網站上刊登了一篇稱為[email protected]（SoundCloud是一個類似音訊YouTube的網站）的文章[附錄1]，講述SoundCloud如何利用BFF模式逐步將其單塊Rails應用遷移改造為支援無線等多種使用者體驗的微服務架構。同期，ThoughtWorks的顧問Sam Newman，也就是《Building Microservices》那本書的作者，在SoundCloud等業界實踐的基礎上，寫了一篇部落格總結了BFF模式的原理、場景和用法[附錄2]，建議大家閱讀。

BFF本質上是一個後端中間層，但是它的作用主要是適配前端不同使用者體驗（無線，桌面，智慧終端等等），所以稱為使用者體驗適配層，它的適配作用主要是：

1. 裁剪和格式化，對後臺的通用資料模型進行適當的裁剪和格式化，以適應不同的使用者體驗展示的需要；

2. 聚合編排，對後臺服務資料進行編排和預聚合，這樣可以有效簡化客戶端邏輯和減少網路呼叫開銷。

下圖展示了一個無線BFF：

Sam推薦理想情況下針對每種使用者體驗型別需要一個BFF（one BFF per user experience），例如Mobile BFF，Desktop BFF，這可以做到職責單一和關注分離（遵循有界上下文原則），但是BFF過多也會造成程式碼邏輯重複冗餘的問題，需要權衡。UI和BFF理想是同一個團隊負責，這樣可以減少溝通協調成本，加快變更迭代速度，這是遵循康威定律的體現。下圖展示了一種BFF和團隊職責邊界劃分方案。

Sam還指出，對於一些跨橫切面的關注點（cross cutting concerns），例如路由，安全認證，日誌監控分析，限流等等，通常可由獨立的閘道器（Gateway）層負責（如Fig 6所示），由獨立基礎設施團隊運維，置於BFF之前，這樣在架構上可以做到職責單一和關注分離，讓BFF開發人員專注於聚合裁剪等業務功能，無需考慮跨橫切面功能。但是如果對運維成本和呼叫效能有額外考慮，跨橫切面的功能也可以直接做在BFF一層。

Fig 6，獨立閘道器層負責跨橫切面功能

三、攜程無線微服務案例分享

攜程網是一家旅遊行業的網際網路公司，其內部有約十幾個大小不同的事業部（也稱戰略事業單位，Strategic Business Unit，SBU）組成，例如機票，酒店，度假等等。三四年前，為迎合無線網際網路的趨勢，和很多其它網際網路公司一樣，公司成立了一個獨立的無線事業部（也是一個SBU），統一為整個公司開發無線應用。下面兩個圖分別是攜程無線H5應用的首頁（Fig 7），和最初的無線架構（Fig 8）：

Fig 7，攜程無線H5首頁

Fig 8，最初的攜程無線架構

架構底層是企業傳統的SOA/ESB/DB服務，架構上層是使用者的無線裝置，中間是使用者體驗適配層BFF。攜程針對兩類不同的使用者體驗分別做了兩個BFF：

1. Mobile App BFF： 針對iOS，Android等Native和Hybrid應用場景，採用定製的TCP協議和二進位制訊息以提升網路傳輸效能，

2. H5 BFF：針對HTML5瀏覽器應用場景，採用標準REST/JSON協議通訊。

最初，攜程無線BFF是單塊的（Monolithic），BFF由無線事業部集中開發，涵蓋其它所有SBU（酒店、機票、度假等）的聚合裁剪邏輯。剛開始，攜程無線應用相對簡單，單塊BFF有優勢，例如開發、測試和部署集中簡單，運維和叢集擴容也比較方便。

但是隨著時間的推移，特別是近兩年，使用無線應用的使用者數成倍增長，無線應用的功能也變得越來越複雜，康威定律逐漸發揮作用，無線SBU和其它業務SBU之間的溝通協調成本越來越高，相互之間還常常因溝通不暢而產生摩擦，交付效率越來越低。同時，單塊BFF還具有程式碼邏輯耦合臃腫，叢集故障概率高，技術棧綁死，阻礙快速創新等單塊架構固有的缺陷。

2014年，攜程對組織架構進行了一次調整，將原無線事業部拆分，將無線團隊打散並安排到各個SBU業務事業部中。為配合組織架構的調整，公司的技術架構團隊也將原來的單塊BFF架構升級到如下的（Fig 9）面向體驗的微服務架構：

新架構中，原來的單塊BFF被拆分到各個SBU獨立開發、測試、部署和運維。新架構中引入了一個API閘道器層（API Gateway），是服務解耦自治的關鍵，主要負責服務反向路由，同時負責限流容錯、安全、日誌、監控等跨橫切面的公共邏輯。BFF解耦之後，攜程微服務架構和組織業務架構進一步對齊，職責更明確，交付效率和創新速度明顯加快。

四、Netflix微服務架構分析

Netflix是一家美國的線上影像租賃服務提供商，早在2012-2013年左右，Netflix就已經建立起了比較成熟的微服務架構體系。值得一提的是，Netflix還把它的整個微服務技術棧開源出來貢獻給了社群，參考[附錄3]，其中包括知名的開源服務閘道器Zuul，服務註冊發現框架Eureka，服務端框架Karyon，客戶端框架Ribbon，容錯元件Hystrix等等，可以說Netflix對微服務架構的發展起了重要的推動作用。下圖展示了Netflix的微服務技術棧，來自Netflix參考應用rss reader[附錄10]，其中帶粉紅色標註的元件和Zuul都是開源的：

下圖是我對Netflix微服務技術棧的一個簡化和抽象，可見整個微服務體系的骨架：

Netflix的微服務體系可以簡化為兩層服務：

1. 邊界服務層（Edge Service Layer），本質上就是BFF，適配前端各種使用者體驗的API層，

2. 中間層服務（Middle Tier Service），Netflix後端的各種微服務的統稱。

Netflix的微服務體系由兩個重要的基礎設施支撐：

1. 服務閘道器（API Gateway），是Netflix微服務的總入口，負責反向路由，安全，限流容錯，日誌監控等跨橫切面的功能，

2. 服務登錄檔（Service Registry），負責閘道器到邊界服務，邊界服務到中間層服務，以及後臺服務之間的軟路由和軟負載。

關於Netflix微服務和API架構的更多內容，推薦參考SlideShare上的兩個ppt：

1. Transforming the Netflix API[附錄12]

2. Netflix’s Global Edge Architecture[附錄13]

下面的一些圖片是從上面兩個ppt中截取出來的。

 

Netflix需要針對超過一千種的裝置提供服務，這對他們的API層（也就是邊界服務層或者BFF層）的設計提出了很大的挑戰，為了應對這種挑戰，Netflix的UI團隊和API團隊通力協作，由API團隊提供通用的API執行時平臺（有點類似PaaS for API的概念），UI團隊則在API執行時平臺上針對不同裝置利用動態指令碼開發不同的API端點，這種模式最大化了UI團隊的效率和靈活性，如下圖所示：

Fig 12，UI和API團隊協同開發API

Netflix的API執行時平臺內部細節和運作方式如下圖所示：

Fig 13，動態指令碼平臺

Netflix的API執行時平臺由API團隊負責開發和運維，其中內建支援：

1. 通用的呼叫後臺服務的SDK；

2. 支援併發呼叫多個後臺服務的非同步服務層（基於RxJava）；

3. 容錯元件Hystrix。

UI工程師利用Groovy指令碼根據前端裝置展示的需要開發API指令碼，通過SDK呼叫後臺服務，對後臺服務和資料進行聚合裁剪，開發完成的指令碼通過端點管理器上傳到API執行時平臺上，最後啟用該指令碼則對應的API端點就能生效對外提供服務。Netflix API執行時平臺也稱為動態指令碼平臺（Dynamic Scripting Platform），更多細節可參考[附錄4]和[附錄11]。

Netflix應用採用前後分離架構，頁面等靜態資源置於CDN上，使用者裝置從CDN直接載入頁面，互動時頁面直接從後臺邊界服務層獲取資料，如下圖所示：

下圖是Netflix API在AWS上的部署架構:

注：最新的Netflix開源專案Falcor[附錄5]表明Netflix同時也採用基於Node/JS技術的裁剪適配層，目的是給前端UI團隊更大靈活性和自主權。Facebook有一個類似的專案GraphQL[附錄16]。

五、SoundCloud微服務架構分析

SoundCloud是一家音訊分享網站，有點類似音訊界的YouTube，最近SoundCloud在SlideShare上分享了他們的微服務架構和實踐。

Fig 16，SoundCloud微服務架構一

上圖是從SoundCloud的一個ppt擷取的微服務層次結構圖，和Netflix/攜程類似，兩個主要層次是：

• 邊界服務層（Edge Layer），相當於BFF，針對不同場景體驗的適配層，例如第三方整合的Public API，嵌入頁面場景的Api-embedded，無線場景的Api-mobile和桌面應用場景的Api-v2。

• 微服務層（Microservices），SoundCloud後臺微服務的統稱，例如messages、stats、likes服務等等。

下圖是從SoundCloud另一個PPT擷取的微服務架構圖。

Fig 17，SoundCloud微服務架構二

有兩點值得關注：

1. SoundCloud將Geoip、限流、安全認證等跨橫切面功能和BFF做在同一層，沒有像Netflix/攜程一樣做在獨立的閘道器層，SoundCloud的這一做法有效能優勢，但同時也增加了BFF層的複雜性；

2. SoundCloud將後臺微服務又分為兩層，最底層的基礎服務層（Foundation Service Layer）和中間的增值服務層（Value-added Service Layer），這種分層方式是SoundCloud根據自己的需要提出的一種邏輯劃分。

關於SoundCloud微服務架構的更多內容，請參考SlideShare上的兩個PPT：

1. BFF Pattern in Action: SoundCloud’s Microservices[附錄14]

2. [email protected][附錄15]

六、微服務架構不是免費的午餐

上面分享的三家公司都是體量比較大的網際網路公司，他們的業務量和團隊規模決定他們很難不採用微服務架構，但是對中小型規模的公司來說，這三家的架構未必是可以直接照搬的，個人認為，解決問題的scope不同，所採用的架構一般也不同，不能盲目照搬。

在業界對微服務架構熱情高漲之際，馬丁福勒在2015年陸續寫了幾篇文章，讓人們更客觀理性地看待微服務，建議大家進一步閱讀：

微服務架構先決條件[附錄7]

馬丁說，你必須長足夠高，才可以考慮使用微服務，這裡的高就是指基本的研發能力，包括：

• 快速的環境提供（Rapid Provisioning）能力，理想有基於雲的環境提供能力。

• 基本的監控 (Basic Monitoring）能力。

• 快速的應用釋出（Rapid Application Deployment）能力。

• DevOps文化。

在沒有建立起這些能力之前，勿輕易跟風采用微服務架構，上面分享的三家公司，都是在具備這些基礎研發能力的基礎上才開展微服務的。

微服務的附加成本[附錄8]

馬丁指出，當業務不復雜，團隊規模不大的時候，單塊架構比微服務架構具有更高的生產率（productivity），原因在於建立微服務架構需要額外的開銷來支援和管理微服務，從而降低生產率；但是隨著業務複雜性的增加和團隊規模的擴大，單塊架構比微服務架構的生產率下降更趨明顯，當複雜性達到一個點，微服務架構的生產率會優於單塊架構，原因在於微服務的鬆散耦合自治特性減緩了生產率的下降趨勢。

注：馬丁在上圖的右下角提出了一個很有意思的觀點，團隊的技能是比單塊或者微服務架構的選擇更重要的因素。說白了，如果團隊能力不行，不管用單塊還是微服務，還是難於管理複雜性。

反過來，如果團隊能力強，不管用單塊還是微服務，都能找到好的管理複雜性的手段，所以說團隊的技能才是管理複雜性的關鍵。

單塊優先(Monolith First)[附錄9]

馬丁說，他不建議企業應用一開始就直接上微服務架構，原因一方面是支援微服務架構需要額外的開銷來管理分散式複雜性，另一方面是剛開始系統複雜度和領域邊界是不清晰的，你不知道該如何正確的切分微服務，所以這種方案常常具有很高的失敗風險。

馬丁建議企業應用走單塊優先的架構思路，先輕裝上陣，贏得時間探索系統的複雜性和領域邊界，當複雜性增加時，拆出部分微服務，隨著團隊對服務邊界更加清晰和服務管理能力的提升，持續拆分出更多微服務，最終演化出微服務架構。

上面分享的案例中，像攜程/SoundCloud都是從單塊架構起步，隨著業務和團隊規模的增長不斷調整其架構，最終演化出微服務架構，SoundCloud從單塊到微服務演化經歷可參考[附錄1]。

七、總結

1、微服務架構是一種支援演化的自適應的架構，微服務架構本身也是演化的結果，架構演化的主要驅動因子是：

• 經濟達爾文：從長遠看，只有那些能更好滿足客戶需求的企業才能生存。簡單講就是業務驅動，業務要求架構靈活易於變更和擴充套件，易於升級替換，釋出快速，高可用能應對不可預測的流量模式，能支援多樣的使用者裝置和體驗，這樣才能加快業務創新的速度，贏得客戶和競爭優勢；

• 無線、智慧裝置和雲等技術的進步和發展；

• 康威定律，即企業的業務、組織和系統邊界要儘可能對齊，以業務領域和微服務為邊界的產品型跨職能團隊能更敏捷地響應市場需求。

2、系統架構的首要目標是管理複雜性，遵循良好的架構原理，如單一職責、有界上下文、關注分離、模組化和分而治之，是管理複雜性的有效手段。在企業應用成長到一定規模以後，微服務架構是管理複雜性的一種行之有效的架構風格。

3、企業要不要用微服務，取決於你的業務複雜度和團隊規模，一般Monolith First。業界大型網際網路企業的微服務架構可以參考和學習，但是不能照搬，解決問題的scope不同，採用的架構也不同。

4、BFF（Backend For Frontend）是應對當前多種使用者體驗的一種模式和最佳實踐，BFF的主要作用是針對不同的使用者體驗對後臺服務和資料做聚合裁剪適配。使用者體驗適配層，BFF，API Orchestration Layer，Edge Service Layer，Device Wrapper Layer是相似概念。

5、Client -> API Gateway -> BFF -> Downstream Microservices，是面向體驗的微服務的標準參考架構。

6、2016年的參考應用架構如下圖所示，引用自ThoughtWorks的文章<<技術棧複雜度飆升給管理者們的啟示>>[附錄6]，特點：

企業後臺採用微服務架構，微服務可以採用不同的程式語言和不同的儲存機制；

企業前臺採用BFF模式對不同的使用者體驗（如桌面瀏覽器，Native App，平板響應式Web）進行適配；

企業後臺採集各種資料，集中儲存，再進行大資料建模、分析和預測，計算出來的資料再以微服務方式反哺給前臺頁面（例如商品推薦）。

附錄

很多不錯的文章，有興趣的同學可以新增郭蕾微信（greenguolei）參與翻譯。

1、[email protected] https://www.thoughtworks.com/insights/blog/bff-soundcloud
2、Pattern: Backends For Frontends  http://samnewman.io/patterns/architectural/bff/
3、Netflix Open Source Software Center  http://netflix.github.io/
4、Netflix Dynamic Scripting Platform http://techblog.netflix.com/2014/03/the-netflix-dynamic-scripting-platform.html
5、Falcor, A Javascript library for efficient data fetching https://github.com/Netflix/falcor
6、技術棧複雜度飆升給管理者們的啟示 http://www.neucloud.cn/article/1399_The-inspiration-of-the-technology-stack-complexity-surge-to-managers.html
7、微服務架構先決條件 http://martinfowler.com/bliki/MicroservicePrerequisites.html

8、微服務的附加成本 http://martinfowler.com/bliki/MicroservicePremium.html

9、單塊優先（Monolith First） http://martinfowler.com/bliki/MonolithFirst.html
10、Introducing the first NetflixOSS Recipe: RSS Reader http://techblog.netflix.com/2013/03/introducing-first-netflixoss-recipe-rss.html
11、Optimizing the Netflix API http://techblog.netflix.com/2013/01/optimizing-netflix-api.html
12、Transforming the Netflix API http://www.slideshare.net/benjaminschmaus/bschmaus-apiworldtransformingnetflixapi
13、Netflix’s Global Edge Architecture http://www.slideshare.net/MikeyCohen1/edge-architecture-ieee-international-conference-on-cloud-engineering-32240146
14、BFF Pattern in Action: SoundCloud’s Microservices http://www.slideshare.net/grandbora/bff-pattern-in-action-soundclouds-microservices
15、Microservices @ SoundCloud http://www.slideshare.net/grandbora/microservices-soundcloud
16、GraphQL A data query language and runtime http://graphql.org/

互動問答

問題：微服務與SOA的區別是什麼？

我覺得兩者體現相通的架構原理：單一職責，有界上下文，關注分離，分而治之。區別在於微服務粒度更細，同時融入了近幾年一線網際網路公司的一些最佳實踐，是服務化的新提法。

問題：API閘道器的反向路由的設計思路能具體說明一下嗎？

攜程的API閘道器基於Netflix的Zuul開源元件。對外暴露一個域名api.ctrip.com，根據第一級目錄做反向路由。

api.ctrip.com/hotel，api.ctrip.com/flight，api.ctrip.com/vacation。每一級目錄，如hotel, flight, vacation對應一個後端BFF叢集的域名，也就是說Gateway裡頭有一張對映表，這張表示是可以動態配置的，可以動態路由，灰度，藍綠部署都可以通過這張對映表做出來。

問題：分散式資料一致性問題在實踐中是怎麼解決的？最終一致性方案中的event-driven和event sourcing或其他方案實踐中是怎麼選型的？有沒有推薦的參考框架或方案？

event-driven和event sourcing是Chris Richardson推崇的，他最近還到DaoCloud做演講。推薦閱讀：

微服務系列之「事件驅動型微服務」

http://blog.daocloud.io/chris-richardson-1/

Chris Richardson 微服務系列之「事件溯源（Event Sourcing）型微服務」

http://blog.daocloud.io/chris-richardson-2/

Chris Richardson 微服務系列之「最佳例項：Eventuate」

http://blog.daocloud.io/chris-richardson-3/

Chris Richardson在他的GitHub上還做了一個event-sourcing的樣例，值得參考：

https://github.com/cer/event-sourcing-examples

我本人覺得還是複雜了，如果簡單場景實時性要求不高，簡單佇列訂閱解決分散式一致性問題。

問題：微服務的分散式事務該怎麼做？如果做二次提交怎麼處理回滾？

分散式事務儘量避免。《如何用訊息系統避免分散式事務？》這篇文章的方法簡單可以參考：http://www.cnblogs.com/LBSer/p/4715395.html

問題：微服務感覺就像是服務的模組化，那麼如果我一個業務需要多個服務那該在哪裡呼叫這些服務，這麼理解對嗎？

微服務本質就是模組化，分散式模組化。“如果我一個業務需要多個服務那該在哪裡呼叫這些服務”：BFF，或者中間層的聚合編排服務。

問題：1、微服務架構下，資料庫該如何部署呢？有的說一定要每個服務單獨部署，有的說要服務共享資料庫，您的意見是怎樣的？ 2、服務在拆分，部署的時候有什麼設計原則嗎？

1、要看情況，不能絕對的。2、拆分理想按照領域邊界，團隊邊界拆，這個也是不斷演化的。

問題：微服務如果變多了有什麼辦法管理呢？極端點如果有一千個怎麼辦？

我當時在eBay維護Trading API，也就是eBay最大的一個API，有差不多160多個API。這個維護成本已經很高了，也是跟eBay的體量相對應的。服務拆分到多細粒度，要根據具體情況的，原則雖然是職責單一，但也要看你的團隊和資源的限制。目前我所在公司40多號人維護一個網站，我估計最多也就拆出20~30個服務，再多維護不過來。原則是一種指導，但是具體實施要看上下文。

企業真的到了一定體量，按業務要求服務越來越多，Netflix內部微服務應該超過千個，阿里巴巴也超過千個，這個時候要靠基礎設施和自動化了，需要微服務基礎設施，監控，DevOps和持續交付平臺支撐成千上萬的微服務，我認為管理複雜性主要靠三個支柱：

• 基礎設施平臺自動化

• 人才密度

• 遵循好的架構原則和最佳實踐

號外號外

有人認為運維的過程像是消防，7*24小時響應異常和危情。事實上，無論做什麼運維，最基本的職責都是保證業務穩定執行。運維以技術為基礎，通過技術保障來提供更高質量的服務。而服務監控技術亦是運維技術的重要組成部分，對服務執行的狀態進行實時的監控，對基礎設施效能進行分析，對App和API進行效能監控，以及對使用者體驗的監控等多種方式來發覺服務隱患。