“四個維度” 講明白什麼是微服務！

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"size","attrs":{"size":16}},{"type":"strong"}],"text":"微服系列文章"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https://xie.infoq.cn/article/83386f6d764984f3b64b760fb","title":""},"content":[{"type":"text","text":"第1篇： “ 四個維度” 講明白什麼是微服務！"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https://xie.infoq.cn/article/e4c9866b723b7c4f9cc272050","title":""},"content":[{"type":"text","text":"第2篇： 微服務涉及的技術生態有哪些？"}],"marks":[{"type":"size","attrs":{"size":12}}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https://xie.infoq.cn/article/13a6973621381b27bbcd9ab45","title":""},"content":[{"type":"text","text":"第3篇： 微服務-爲什麼要有服務發現與註冊？"}],"marks":[{"type":"size","attrs":{"size":12}}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"horizontalrule"},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"一、從康威定律說起"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"關於微服務的理論思想，我們可以從一個著名的定律說起---康威定律，康威定律是一個叫"},{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"梅爾文·康威"},{"type":"text","text":"的程序員，他在1968年發佈了一篇文章，文中論述了設計系統的組織與系統本身的關係，並列舉了各個不同行業的真實案例，最後得出了結論：“oganizationrs which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/20/209cb82770a8df80753099d0e3006163.png","alt":"","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"​"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"大致的意思就是"},{"type":"text","marks":[{"type":"italic"},{"type":"strong"}],"text":"："},{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"系統設計（產品結構）等同組織形式，每個設計系統的組織，其產生的設計等同於組織之間的溝通結構"},{"type":"text","marks":[{"type":"italic"},{"type":"strong"}],"text":"，簡單一點理解就是："},{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"系統設計受限於設計系統的組織架構形式，用大白話來說就是：有什麼樣的組織架構就會設計出什麼樣的系統架構。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 當然，這個結論在當時並沒有上升到定律的高度，直到《人月神話》、《架構之美》這兩本書暢銷書都引用了其觀點並“大肆吹捧”，康威定律才慢慢傳播開，最終成爲了與摩爾定律齊名的軟件工程定律。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"雖然時間過去了50多年，但這些結論依然歷舊彌新。當一個組織增長到一定的規模，組織之間的溝通、協調就會出現低效與冗餘，爲應對內外部環境，組織就要進行適當的變革。在互聯網公司這種變革的成果，就是誕生了一個個獨立作戰的小團隊，無論是騰訊的“大公司小團隊理念”，還是亞馬遜貝佐斯提出的“二個披薩餅原則”，（一個團隊的規模最多隻能用兩個披薩餅餵飽）都印證了這點。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"同樣，隨着組織的變革也影響着系統架構的設計，因爲系統架構一個十分重要的職責就是："},{"type":"text","marks":[{"type":"italic"},{"type":"strong"}],"text":"“解決團隊分工協助問題，系統架構體現了組織的溝通與協助方式。這正是康威定律所說的“系統設計（產品結構）等同組織形式”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"二、單體架構與微服務"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"有了康威定律的理論基礎，從組織的維度我們可以認爲微服務的本質是："}]},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"“將一個個業務功能拆分出來，並由一個微型團隊來開發、構建、運維，團隊與團隊之間通過定義清晰的邊界進行溝通”。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"下面將通過兩張圖，更細緻的理解微服務的概念："}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/a5/a50ec933458e802d6b0452abeec12b31.png","alt":null,"title":"單體架構","style":[{"key":"width","value":"100%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"先看第一張圖，這是典型的單體架構風格，由人數衆多的大團隊在一個單體裏面進行協助開發，在業務複雜程度低，團隊規模不大時，這種方式團隊能聚焦核心業務，快速響應。但隨着業務的不斷髮展，團隊人數的不斷擴張，系統的規模與複雜性會成指數級增長，整個研發過程就會面臨着3個問題："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"人數衆多，團隊之間溝通協調困難，信息不一致（可以參考項目管理中的溝通途徑計算）"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"項目工程龐雜，各類庫與組件的依賴關係錯綜複雜，大量重複性代碼，項目推進舉步維艱；"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"代碼管理、版本管理變得困難，構建編譯時間變長，運維部署困難，系統啓動時間變長；"}]}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"這些問題，直接影響着團隊的交付效率，影響着系統的可用性、可擴展、可伸縮等。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"而面對這些問題的解決之道就是微服務，我們再看第二張圖微服務的架構風格。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/ee/ee8dbaf4bfc97ccf29f5ccc829e0a427.png","alt":null,"title":"微服務架構","style":[{"key":"width","value":"100%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我覺得有必要先個微服務下一個定義，這裏我引用軟件領域泰斗級人物“馬丁·福勒”他對微服務的定義。對於馬丁·福勒，你可能沒聽說過他，但是作爲一個程序員你不可能不知道他的作品《重構》，就在今年5月份《重構》出了第二版，更不可能不知道由他與其他15爲軟件泰斗共同創造的“敏捷軟件宣言”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務定義："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"“微服務架構風格是以一組小服務來開發單個應用程序的方法，每一個服務運行在自己獨立的進程中並使用輕量的方法通信，通常是一個HTTP API接口。這些服務圍繞相關業務範圍構建並且由全自動化部署機器獨立部署。這些服務只需要最低限度的管理，可以用不同的編程語言去編寫並且使用不同的數據存儲技術”"},{"type":"text","marks":[{"type":"color","attrs":{"color":"#e36c09","name":"user"}}],"text":"。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"基於微服務的定義我們可以總結出微服務的一些特徵："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/3d/3d78d2bac953e6b4f82bc87ec508ff09.png","alt":null,"title":"微服務特徵","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#3399ea","name":"user"}},{"type":"strong"}],"text":"1）服務小而美："},{"type":"text","text":"微服務是以一組小的服務組成，一個重要的特點就是小，至於具體多小，有一些不同的聲音，這個不能一概而論，要看具體情況。我們需要使用領域建模的方法來定義服務的粒度，領域建模的知識我會在後面的文章中詳細的介紹。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#3399ea","name":"user"}},{"type":"strong"}],"text":"2）服務獨立自治："},{"type":"text","text":"獨立自制是微服務一個顯著的特徵，主要體系在幾個方面，第一，微服務由獨立的團隊來開發；第二、微服務可以使用不同的平臺與語音；第三，獨立於具體項目已產品的形式存在； 第四，微服務運行在獨立的進程中，可獨立部署；"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#3399ea","name":"user"}},{"type":"strong"}],"text":"3）服務鬆散耦合："},{"type":"text","text":"微服務將業務劃分清晰的邊界，再封裝到一個獨立的服務中，符合軟件設計的單一職責與最少依賴原則，微服務將系統的抽象程度提到了更高的層次，將系統對代碼或組件的依賴轉換爲對接口，對服務的依賴；"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#3399ea","name":"user"}},{"type":"strong"}],"text":"4）服務互聯互通："},{"type":"text","text":"微服務強調小，輕量，服務通過相互連通組成複雜的業務功能，服務通信方式可根據具體場景，選擇基於HTTP Restfull的輕量級協議，或是效率高的RPC協議，甚至可以選擇基於消息隊列的異步調用方式等；"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#3399ea","name":"user"}},{"type":"strong"}],"text":"5）非中心化治理："},{"type":"text","text":"去中心化是微服務的又一個重要特徵，去中心包括數據非中心化，管理去非中心化，微服務採用非集中化的數據存儲，各個服務使用自己獨立的數據存儲，微服務也沒有一個集中的服務管理器。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#3399ea","name":"user"}},{"type":"strong"}],"text":"6）演進式設計："},{"type":"text","text":"演進式架構已增量的、非破壞的變更作爲第一原則，演進式設計也是微服務所提倡的。例如，要對一個巨型單體應用進行微服務轉型，肯定不是把這個大的單體應用直接幹掉不要，建一個新的微服務平臺出來，而是要以增量的、非破壞的方式把某項業務一步步抽離形成新的服務。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"三、 微服務帶來的問題與挑戰"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"架構設計是一門權衡、取捨的藝術，沒有銀彈，更沒有十全十美的架構，微服務架構爲我們帶來了如：“可擴展性”、“容錯性”、“靈活性”等諸多優點。我們收穫這些好處的同時，也一定會帶來某些弊端與挑戰，這些挑戰可以從四個方面來說："}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#3399ea","name":"user"}}],"text":"1）分佈式帶來的通信複雜性與不確定性"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"對於單體應用，要完一個業務操作，我們通過本地方法調用，這些調用都在同一個進程內完成。進程內地的方法調用或類庫調用，由平臺語言本身來提供，比如JVM通過線程棧，能提供可靠、確定的調用機制，並且時間延長几乎可以忽略不計。而在分佈式環境中，要完成一個業務操作，服務之間需要跨進程，跨網絡進行相互調用，我們稱之爲遠程方法調用，這兩種調用方式有着這本質的區別，進程內調用習以爲常的事情，在遠程調用時就成了必須要面對的問題，這些問題包括："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"服務的調用方（消費者）怎樣找到被調用（提供者）方？"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果某個依賴服務掛了（進程死了、網絡異常，服務器宕機）怎麼辦？"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"服務接口需要暴露在網絡上，接口的安全怎麼保證？"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"業務代碼分散在各個進程中，那統一處理的代碼怎麼辦（比如異常、日誌）？單體中我們有AOP編程"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果服務調用鏈層級太深，時間延遲怎麼辦？"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"對於一個業務bug、或線上問題涉及多個服務調用，怎麼快速定位、排查問題？"}]}]}]}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#3399ea","name":"user"}}],"text":"2）非中心化帶來的數據不一致性"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務的一個重要特徵是數據的非中心化存儲，各個服務使用自己獨立的數據庫。這就帶來了一個嚴峻的挑戰，就是數據庫的一致性問題。在單體系統中，使用單一數據庫，程序員只需要關心最的核心業務問題，我們用數據庫的ACID特性，就能輕易的保證數據的一致性，在代碼框架的支持下只需要一個標記就能搞定一個事務處理。但是在分佈式數據庫中要做到這些，就是個非常棘手的問題，需要我們做很多額外的工作，同樣對於像報表查詢，統計業務從前一個sql語句能搞定的事情，數據非中心存儲後就會非常麻煩。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#3399ea","name":"user"}}],"text":"3）衆多服務帶來構建、配置、測試、部署的困難性"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"軟件系統最終是要經過編譯、測試、部署到多個環境進行最終驗證，最後再依次部署到生產環境，同時還要考慮生產環境的回滾策略，這些流程在單體應用中只是規模，體積比較大，但畢竟數量是少數的。我們需要可能只是一些細心與耐心。但系統被拆分成諸多微服務之後，假設有20個，同樣的事情，重複的勞動我們需要做20次並且保存每次都不能出錯，量變引起質變，當服務超過一定數量，我們要面對的不僅僅是重複勞動的問題。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#3399ea","name":"user"}}],"text":"4）業務解耦帶來的微服務拆分困難性"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"對於單體應用，如果我們的業務設計做的不好，模塊化劃分不到位，後果可能還沒有那麼嚴重，畢竟所有的數據都在一個數據庫中，所有的代碼也都可以進程內調用，大不了我就加一層來解決，實在不行就加兩層（玩笑話），但是，我們想象一下，如果微服務在業務設計時沒有規劃好，把不該放一起的放到一起，該放一起的強行拆開，整個微服務就成了一團亂麻，遠程調用的開銷，服務的治理會是一場災難。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務強調的是基於業務功能構建，業務功能之間要鬆散耦合，有明確邊界。然後，對於一個複雜業務系統，在設計早期要做的這點並非易事。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"根據墨菲定律--“凡是可能出錯的那它一定會出錯”"},{"type":"text","marks":[{"type":"color","attrs":{"color":"#e36c09","name":"user"}}],"text":"，"},{"type":"text","text":"選擇微服務就一定會遇到上述我說的這些問題。"}]}]},{"type":"heading","attrs":{"align":null,"level":1}},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"四、微服務的適應性"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"看到微服務這麼多困難與挑戰，是不是感到迷茫與沮喪，確實，“沒有銀彈”，“沒有神丹妙藥”，微服務不一定適合所有公司、所有項目。那麼我們應該怎樣權衡微服務與單體架構呢？這裏就涉及到一個經濟學中邊際成本與收益的問題。我又得請出我們的大神“馬丁.福勒”了，大神在一篇“微服務的適用性”文章中用一張圖清晰的說明了微服務的適用場景。我們先來看看這張圖："}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/ec/ec9b343586a9af659d3c54b26c932e09.png","alt":null,"title":"​微服務 系統複雜性與生產力關係","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"圖上的X軸表示系統複雜性，Y軸表示生產力，兩條曲線表示微服務與單體應用，在兩個維度上的表現。當系統複雜性比較小的時候（X軸靠近左邊），單體應用的生產力要高於微服務，其實這很好理解，因爲微服務要考慮，自動化部署、服務監控、故障處理、數據一致性等諸多問題，而這些對於業務系統本身來說都是額外的工作。當軟件複雜性不高，團隊規模不大時，這些工作會佔據整個研發工作的很大比重。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當系統複雜性變大時，微服務額外部分的工作佔整個研發工作的比重變小，而微服務帶來的收益越來越大，這時整個研發的生產力並沒有像單體架構那樣直線下降，所以微服務能夠在系統複雜性增加時，還能持續的保持良好的生產力。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在嘗試微服務轉型之前，我們需要結合公司的實際情況，考慮微服務帶來的挑戰與收益，再判斷我們是否真的需要微服務。“馬丁.福勒”的建議是："},{"type":"text","marks":[{"type":"italic"},{"type":"strong"}],"text":"“ "},{"type":"text","marks":[{"type":"italic"},{"type":"color","attrs":{"color":"#e36c09","name":"user"}},{"type":"strong"}],"text":"除非系統過於複雜而無法作爲一個整體進行管理，否則甚至不要考慮使用微服務，大多數的應用系統應該使用單體架構，只是要注意在單體內做好模塊化，而不是直接使用微服務”"},{"type":"text","marks":[{"type":"color","attrs":{"color":"#e36c09","name":"user"}}],"text":"。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務架構充滿刺激與挑戰，但好消息是，對於大多數項目與團隊，並不需要從零開始，我們只需“站在巨人的肩膀上”，領會他們的設計精髓、用好他們的成果即可。下面的文章我們將重點介紹微服務架構的具體技術方案與通用實踐。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}