前言

首先，微服務不是一個名字，而是一個架構的概念，就像Restful不僅僅是描述api的格式，而更多的是描述基于Restful API的架構是一樣的。微服務架構（MSA）是對原來的大型系統而言的，通過橫向或者縱向、業務或者架構切分，將一個大型的系統分散成很多微型小系統。當系統復雜到一定程度時，幾十號人共同維護一個系統的效率很低，而且出問題的風險也很高。

這時候就需要對系統進行切分，很早之前提出的SOA系統，和微服務的架構理念不謀而合。大家現在使用的基于RPC框架（dubbo、thrift等）的架構也可以視為一種微服務。微服務到現在為止還沒有確切的邊界和定義，貌似計算機上很多概念都定義不出來邊界。但是，我理解微服務之間的通信是http通信，傳統rpc調用方式并不是嚴格的微服務，因為他不能自理，需要依賴，比如可能必須某個rpc服務Producer存在的情況下，rpc服務的Consumer才能啟動起來。所以，下文中的討論，我都以微服務之間以http通信為前提。

微服務有什么好處

解耦：對于我們底層程序員而言，看得見的好處就是解耦。我要實現一個功能，可能并不需要很深入的了解別人的代碼，因為程序員嘛，可能都覺得別人的代碼是個渣渣（［哭笑不得］）。我可以新作一個微服務，這個服務為其他功能提供服務，又不依賴于原來已有的功能，至于業務邏輯，可以一邊上手一邊熟悉 內聚，可以獨立部署：意思就是我維護的這個微服務，可以獨立部署，對其他服務不會是強依賴，不會存在因為其他服務不存在而造成我自己的服務不能啟動或者不可用的問題。

分布式：微服務架構下不存在一個特別大的系統包含很多中心功能，這樣也能提高容錯性，一個服務的癱瘓并不會讓整個系統癱瘓 權限驗證：微服務是高度內聚的服務，我自己的這個服務，我可以定制任意合理規則，而這個規則又只適用于我自己的服務。相比于dubbo RPC調用，http微服務調用的權限驗證可以更直接更嚴格更定制化，而rpc調用時的權限驗證，我個人始終覺得不能做的很優雅 數據分開治理，自帶分庫屬性：原來的大系統使用一個數據庫，當數據很多流量很大時，就會涉及到分庫分表。

而微服務下，每個服務是否使用數據庫，數據庫是和其他服務公用還是自建，都有很大靈活性，即我覺得微服務自帶分庫分表屬性 系統不會被長期限制在某個技術棧上，在微服務的架構下，整個系統不會受限于java或者nodejs 或者go，而是大家協同不沖突，全部http協議，json格式 各個模塊的單元測試容易自動化 等

微服務面臨的挑戰

通信，http請求速度慢，通常一個操作可能會涉及到多個微服務的相互調用，如果為了完成一個操作而多次從服務端調用不同的微服務，http請求的耗時可能會成為瓶頸，如圖1所示。

客戶端與服務端的通信需要一個 API GateWay：通常情況下，客戶端和微服務們不在一起，而各個微服務會集中部署在一個機房，那微服務之間的互相調用是很快速的，但是客戶端和微服務之間的調用會是耗時的。而且，用戶的一個動作不能在客戶端進行多次連續調用，這樣一來速度慢，二來會有泄漏系統架構的風險。正常情況下，在客戶端和微服務架構之間會有一個API GateWay。

如圖1變成圖2所示，GateWay最重要的作用是為客戶端提供后臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，為了解決API Gateway單點故障點或者性能瓶頸，通常Gateway也是一個集群，而且客戶端的訪問控制、賬號管理、登錄管理等切面通常會在這里處理

微服務很多時，整個鏈路可能很長，調用失敗的風險高，而且e2e自動化測試會成為一個問題 服務注冊和服務發現，我司有自己的服務管理系統。我推薦etcd。Google開源的Kubernetes（k8s）貌似也是使用的這個。 分布式事務，這個是微服務系統的大難點，可能需要根據自己系統的情況和業務需求進行定制了，我推薦補償性分布式事務和基于消息的分布式事務。（下次有時間介紹一下常用的集中分布式事務要怎么做）

基于微服務架構和架構實施過程中存在的優點和缺點：

采用微服務架構的優點

采用微服務架構可以更好的實現DevOps開發運維一體化，同時因為微服務架構下各個微服務模塊相對獨立和松耦合，因此在后續業務變更的分析和處理中往往能夠更加敏捷快速的響應，同時相對影響也最小。

整個業務系統水平擴展更加容易，單體應用要擴展往往數據庫是大問題，而在微服務架構下實現了單體應用的垂直拆分，可以更加容易的通過廉價的X86服務器資源來實現水平擴展。

通過微服務架構可以更好的提升各個模塊的可復用性和可組裝性。通過微服務架構更好的實現了原單體應用內部各個組件或模塊的徹底解耦，通過解耦本身也降低了原單體應用內部的復雜度。

可以使研發過程根據敏捷和小團隊化，包括和敏捷軟件開發最佳實踐更好的匹配，每個微服務模塊都可以形成獨立的敏捷小團隊進行開發和部署上線。

進一步在傳統單體應用內部實施SOA參考架構思想，體現業務能力組件化，組件能力服務化，同時也可以更好貫徹各個能力中心和前端應用組件的分離，實現共性能力下沉和復用。

采用微服務架構的缺點或困難

微服務架構需要開發團隊本身具備較強的團隊管理能力，軟件研發技能，因為管控的粒度單位已經從原有業務系統變化為了微服務模塊。

微服務架構本身會提升開發難度和工作量，特別是上層的跨多個微服務模塊或組件的功能應用的實現，往往需要在前端進行服務組合而不是傳統方式在數據庫層做SQL關聯。

由于各個微服務模塊完全相對獨立和松耦合，因此對于跨多模塊業務帶來的分布式事務問題是必須解決或找尋替代方案。特別是在微服務架構下數據庫已經進行了垂直拆分，對于跨庫訪問本身的分布式事務一致性問題是最需要和重視的問題。

服務的治理將成為實施微服務架構中重點問題，包括了服務全生命周期管理，服務后期的運維和監控，性能分析，服務鏈監控等。如果企業本身的IT治理和SOA管控治理能力弱，那么及時開始正常實施了微服務架構，到了后期的運維管控也很難做的很好。其核心原因還是管控的粒度更加細，需要管控的微服務模塊，服務接口都會呈現指數級增加。

集成復雜度增加，任何徹底的分解都將帶來集成的復雜度，即模塊在集成時候需要外部微服務模塊更多的配合。

部署復雜度增加，由于微服務模塊需要獨立部署，往往涉及到多達上100個容器的安裝和部署和集成等相關工作，這也是需要和Docker集成并實現自動部署的一個原因。

微服務很多時，整個鏈路可能很長，調用失敗的風險高，而且e2e自動化測試會成為一個問題 服務注冊和服務發現，我司有自己的服務管理系統。我推薦etcd。Google開源的Kubernetes（k8s）貌似也是使用的這個。 分布式事務，這個是微服務系統的大難點，可能需要根據自己系統的情況和業務需求進行定制了，我推薦補償性分布式事務和基于消息的分布式事務。（下次有時間介紹一下常用的集中分布式事務要怎么做）