架構與微服務本質論

爲應對現在無線優先和全渠道用戶體驗的需求和挑戰，咱們該如何設計靈活的面向體驗的微服務架構？它有哪些模式和最佳實踐？攜程，Netflix和SoundCloud這些知名互聯網公司是如何實踐面向體驗的微服務架構的？在過去的時間裏，大牛馬丁福勒對微服務有哪些新的觀點？

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

本次分享的主題包括：

微服務架構原理

用戶體驗適配層（Backend For Frontend）

攜程無線微服務案例分享

Netflix微服務架構分析

SoundCloud微服務架構分析

微服務架構不是免費的午飯

總結

本次分享也是應架構羣內一些朋友的要求，將以前零散分享的內容總結成文，本次分享過程當中會貼出相關內容參考連接（其中有些來自SlideShare和Netflix techblog的連接須要FQ訪問），供有興趣的朋友進一步學習。

1、微服務架構原理

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

單一職責（Single Responsibility），一個服務應當承擔儘量單一的職責，服務應基於有界的上下文（bounded context，一般是邊界清晰的業務領域）構建，服務理想應當只有一個變動的理由（相似Robert C. Martin講的：A class should have only one reason to change），當一個服務承擔過多職責，就會產生各類耦合性問題，須要進一步拆分使其儘量職責單一化。

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

模塊化（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，團隊結構和系統架構匹配

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

2、用戶體驗適配層（Backend For Frontend）

衆所周知，隨着無線技術的發展和各類智能設備的興起，互聯網應用已經從單一Web瀏覽器時代演進到以API驅動的無線優先（Mobile First）和麪向全渠道體驗（omni-channel experience oriented）的時代，以下圖所示：

 

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

應用架構的新挑戰是：

用戶接入形式的多樣性，無線（手機、Pad），Web，互聯網電視，第三方合做應用等等，各類用戶設備的屏幕大小，操控體驗方式各不相同，例如，手機設備的屏幕較小，可以展現的數據量小，交互方式以觸控爲主，也可經過條形碼掃描器；

有些用戶設備的帶寬受限，同時應用的UI通常宿主在客戶端，有些頁面須要組合好幾個後臺業務服務的數據和功能，若是直接在客戶端發起對多個後臺服務的調用，勢必形成大量網絡開銷影響性能，這個有點相似數據庫查詢中的n+1問題。

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

BFF本質上是一個後端中間層，可是它的做用主要是適配前端不一樣用戶體驗（無線，桌面，智能終端等等），因此稱爲用戶體驗適配層，它的適配做用主要是：

裁剪和格式化，對後臺的通用數據模型進行適當的裁剪和格式化，以適應不一樣的用戶體驗展現的須要；

聚合編排，對後臺服務數據進行編排和預聚合，這樣能夠有效簡化客戶端邏輯和減小網絡調用開銷。

下圖展現了一個無線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，獨立網關層負責跨橫切面功能

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

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

 

Fig 7，攜程無線H5首頁

 

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

架構底層是企業傳統的SOA/ESB/DB服務，架構上層是用戶的無線設備，中間是用戶體驗適配層BFF。攜程針對兩類不一樣的用戶體驗分別作了兩個BFF：

Mobile App BFF： 針對iOS，Android等Native和Hybrid應用場景，採用定製的TCP協議和二進制消息以提高網絡傳輸性能，

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

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

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

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

 

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

4、Netflix微服務架構分析

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

 

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

 

Netflix的微服務體系能夠簡化爲兩層服務：

邊界服務層（Edge Service Layer），本質上就是BFF，適配前端各類用戶體驗的API層，

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

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

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

服務註冊表（Service Registry），負責網關到邊界服務，邊界服務到中間層服務，以及後臺服務之間的軟路由和軟負載。

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

Transforming the Netflix API[附錄12]

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團隊負責開發和運維，其中內置支持：

通用的調用後臺服務的SDK；

支持併發調用多個後臺服務的異步服務層（基於RxJava）；

容錯組件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]。

5、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微服務架構二

有兩點值得關注：

SoundCloud將Geoip、限流、安全認證等跨橫切面功能和BFF作在同一層，沒有像Netflix/攜程同樣作在獨立的網關層，SoundCloud的這一作法有性能優點，但同時也增長了BFF層的複雜性；

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

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

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

Microservices@SoundCloud[附錄15]

6、微服務架構不是免費的午飯

上面分享的三家公司都是體量比較大的互聯網公司，他們的業務量和團隊規模決定他們很難不採用微服務架構，可是對中小型規模的公司來講，這三家的架構未必是能夠直接照搬的，我的認爲，解決問題的scope不一樣，所採用的架構通常也不一樣，不能盲目照搬。

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

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

 

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

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

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

快速的應用發佈（Rapid Application Deployment）能力。

DevOps文化。

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

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

 

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

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

反過來，若是團隊能力強，無論用單塊仍是微服務，都能找到好的管理複雜性的手段，因此說團隊的技能纔是管理複雜性的關鍵。

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

 

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

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

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

7、總結

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

經濟達爾文：從長遠看，只有那些能更好知足客戶需求的企業才能生存。簡單講就是業務驅動，業務要求架構靈活易於變動和擴展，易於升級替換，發佈快速，高可用能應對不可預測的流量模式，能支持多樣的用戶設備和體驗，這樣才能加快業務創新的速度，贏得客戶和競爭優點；

無線、智能設備和雲等技術的進步和發展；

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

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

三、企業要不要用微服務，取決於你的業務複雜度和團隊規模，通常Monolith First。業界大型互聯網企業的微服務架構能夠參考和學習，可是不能照搬，解決問題的scope不一樣，採用的架構也不一樣。

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

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

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

企業後臺採用微服務架構，微服務能夠採用不一樣的編程語言和不一樣的存儲機制；

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

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

 

附錄

不少不錯的文章，有興趣的同窗能夠參與翻譯。

一、BFF@SoundCloud https://www.thoughtworks.com/insights/blog/bff-soundcloud

二、Pattern: Backends For Frontends http://samnewman.io/patterns/architectural/bff/

三、Netflix Open Source Software Center http://netflix.github.io/

四、Netflix Dynamic Scripting Platform http://techblog.netflix.com/2014/03/the-netflix-dynamic-scripting-platform.html

五、Falcor, A Javascript library for efficient data fetching https://github.com/Netflix/falcor

六、技術棧複雜度飆升給管理者們的啓示 http://www.neucloud.cn/article/1399_The-inspiration-of-the-technology-stack-complexity-surge-to-managers.html

七、微服務架構先決條件 http://martinfowler.com/bliki/MicroservicePrerequisites.html

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

九、單塊優先（Monolith First） http://martinfowler.com/bliki/MonolithFirst.html

十、Introducing the first NetflixOSS Recipe: RSS Reader http://techblog.netflix.com/2013/03/introducing-first-netflixoss-recipe-rss.html

十一、Optimizing the Netflix API http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

十二、Transforming the Netflix API http://www.slideshare.net/benjaminschmaus/bschmaus-apiworldtransformingnetflixapi

1三、Netflix’s Global Edge Architecture http://www.slideshare.net/MikeyCohen1/edge-architecture-ieee-international-conference-on-cloud-engineering-32240146

1四、BFF Pattern in Action: SoundCloud’s Microservices http://www.slideshare.net/grandbora/bff-pattern-in-action-soundclouds-microservices

1五、Microservices @ SoundCloud http://www.slideshare.net/grandbora/microservices-soundcloud

1六、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，或者中間層的聚合編排服務。

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

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

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

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

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

1.基礎設施平臺自動化

2.人才密度

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

最後給你們分享一些我本身收集的架構資料，關注我，私信發送「JAVA」便可獲取如下資料：