為什么會產生微服務架構，原來是這些原因
Web應用架構受系統用戶量、開發人員組織方式影響嚴重。過去二十年互聯網迅速發展，Web架構也從單體式演進出微服務，背后還有比如 Martin Fowler 提出的理論支撐。雖然每個人都聽說過微服務，但是很多人并不太清楚為什么要這么做，應該怎么做，怎么拆。要回答這個問題我認為需要從Web架構的演化歷史的高度去理解這些架構設計中的取舍。
首先我們改進系統架構的目的是為了滿足系統可靠性、并發量以及快速開發的需求。所有的改進方案都是為了解決這其中一個或多個問題而產生的。
單體結構
單體結構
最開始Web服務器、數據庫全部部署在同一臺服務器上，這也是最簡單的應用架構，通常公司早期項目都采用這種方式。在很長一段時間里單體結構可以滿足系統快速開發與并發量的需求。當用戶量越來越大，通常會數據庫性能會成為系統瓶頸，此時可以將Web業務與數據庫部署在不同服務器上，增強數據庫服務器的配置并做讀寫分離等提高系統的吞吐量與可用性。
與此同時也可以將業務系統等價部署在多臺服務器上來提高系統吞吐量，但整體上這仍然是一個單體應用。
單體等價部署
隨著用戶、數據量進一步增大，單體應用的缺點會進一步顯露出來，比如：
- 耦合嚴重、復雜度高、可靠性差 ：單體應用越來越來很多業務會耦合在一起，一但某些模塊出現Bug會影響整個系統正常運行，業務代碼的耦合也會形成開發人員的依賴造成新業務難以推進
- 增加技術債、部署困難效率差 ：技術債越來越多容易會造成“不壞不修“的囧境，已完成的代碼難以被修改以防止系統某個地方意料之外的調用。同于由于代碼量大導致應用全量部署困難
- 系統吞吐量受限、阻礙技術進步 ：單體應用難以進一步擴展使系統吞吐量受限，同時單體應用要求使用統一技術平臺或解決方案，要想引入新語言或框架會非常困難
拆分
應用規模越來越大，首先遇到瓶頸的可能就是數據庫系統，面對數據庫壓力通常我們可以對數據庫做拆分把負載分擔到不同的服務器上來解決，通常數據庫拆分有兩種方案：
- 垂直拆分：對不同的業務系統如賬戶、搜索、推薦系統使用不同的數據庫
- 水平拆分：對于大表，比如十億百億級別的，進行多表拆分
數據庫水平拆分與業務邏輯耦合緊密，需要具體問題具體分析，通常這是一個非常復雜的問題。后來人們引入 NoSQL、NewSQL 用分布式概念在數據庫層屏蔽掉數據庫的水平拆分，比如 NoSQL 的 MongoDB Sharding，NewSQL 的 TiDB。
同樣的在業務層上我們也可以通過垂直拆分和水平拆分將單體業務拆成不同的服務，服務之間通過約定好的協議通信，以提高人員開發效率，實現多機部署冗余部署來提高系統可用性與吞吐量。
微服務
我們都知道微服務是一種提倡將單一服務拆分成一組小服務、服務之間相互協調、配合，提高開發效率，最終為用戶提供價值的思路。說到微服務那么這里面最重要的一個問題就是服務應該怎么拆。微服務作為 SOA(Service Oriented Architecture)思想的一種具體實踐我們首先想到的就是按照不同的業務系統做垂直拆分，如下圖所示：
SOA垂直拆分
按業務系統對單體應用做垂直拆分，不同的業務線完全可以獨立配備產品經歷與工程師同步開發維護，將不同業務線解耦出來有不同團隊維護。但上圖是一種理想情況，各系統拆分力度比較大，系統之間不需要更詳細的通信。如果是被拆除出了的子系統之間有大量的數據交互與調用，網關模式便不是一種很好的實踐，通常會將各業務子系統接入一個數據總線用 ESB(Enterprise Service Bus)模式來進行數據交互，各子系統與數據總線進行數據交換便需要對子系統做統一管理，這遍有了 服務治理 的概念，用一套統一的保準來處理各子系統的注冊、權限、監控等，目前有很多 ESB 開源或閉源的解決方案，這里不再贅述。
垂直拆分將各業務子系統解耦出來，但是每次請求在不同階段遇到的瓶頸與負載是不一樣的，因此我們對可以使用水平拆分的思路對服務進行拆分：
水平拆分
首先用戶請求通過http協議到達網關，網關將json數據格式轉為protobuf，通過tcp長鏈接與服務層、數據層通信獲取目標數據然后返回給用戶。這樣拆分加長了用戶請求鏈路時延，但是如果服務全部部署在同一內網，而且使用protobuf格式通信那么這個時延在幾十毫秒內是完全可以接受的。業務層與數據層完全解耦便可以輕松將不同類型的服務進入冗余部署，同時在不動業務層的同時修改它的數據存儲方式。
如果我們對系統即做垂直拆分也做水分拆分，那么就有了微服務的樣子,
水平拆分
每級服務只能調用比他低級別的服務，如果搜索服務層只能掉賬戶接口層服務而不能調賬戶服務層接口，這樣可以用來避免服務A調用服務B，而服務B同時又調用了服務A的循環調用問題。但是這樣的拆分粒度仍然不夠的，比如搜索系統和推薦系統都要調用賬戶系統的一些基礎查詢、修改邏輯，那么需要在搜索與推薦的服務層兩次實現同樣的代碼嗎，這樣顯然是不合理了，任何不能復用的設計顯然都是有問題的。如果通過編寫SDK庫提供Jar包的模式去實現這個功能呢?，顯然也存在問題比如推薦系統是Python實現，而搜索系統是Java實現的呢?所以這里我們將每個子系統可共用代碼部分也單獨抽取出來作為一個服務。
水平拆分2
這樣拆分后的系統可以靈活部署，獨立開發，并且各模塊服務使用的技術棧相對獨立不受限制。但是同時拆分也將系統的網絡拓撲便的復雜，運維負擔加重，服務間的依賴使得服務接口的調整成本非常高。服務增多的同時對服務治理的要求也更高，需要專門做服務的發現、注冊、鑒權、監控等系統功能。
