微服務第一講
什么是微服務
微服務的概念定義沒有特別官方的統(tǒng)一語言，參考Chris Richardson的《MicroServicesPatterns》一書中的定義：把應用程序功能性分解為一組服務的架構風格。
這個概念是通過MartinAbbott和Michael Fisher的名著《The Art of Scalability》中描述的三位可擴展模型（擴展立方體）而來。
X軸擴展：在多個實例之間實現(xiàn)請求的負載均衡?？梢院唵卫斫馔ㄟ^負載均衡對某個應用實現(xiàn)水平擴容。
Y軸擴展：根據(jù)功能把應用拆分為服務。也就是單體應用到微服務的演變。
Z軸擴展：根據(jù)請求的屬性路由請求?？梢院唵卫斫鉃槁酚删W(wǎng)關，根據(jù)不同的緯度將交易路由到指定的應用服務上。
X軸和Z軸擴展有效地提升了應用的吞吐量和可用性，Y軸擴展解決了單體煉獄問題。優(yōu)點 | 缺點 | |
單體服務 | 應用開發(fā)簡單 | 過度臃腫造成復雜性升高（臟泥球理論） |
易于對應用程序進行大規(guī)模的更改 | 開發(fā)速度慢，交付周期變長 | |
測試相對簡單直觀 | 很難保證交付質量 | |
部署簡單明了 | 難以擴展（主要是基礎資源層面） | |
橫向擴容成本較低(加一層負載均衡) | 需要長期依賴某個可能已經(jīng)過時的技術棧 | |
微服務 | 使大型的復雜應用程序可以持續(xù)交付和持續(xù)部署 | 服務的拆分和定義是一項挑戰(zhàn)。(可以根據(jù)DDD或者業(yè)務功能拆分) |
每個服務都相對較小并容易維護 | 分布式系統(tǒng)帶來的各種復雜性，使開發(fā)、測試和部署變得更困難 | |
服務可以獨立部署 | 當部署跨越多個服務的功能時需要謹慎地協(xié)調更多開發(fā)團隊（變更管理） | |
服務可以獨立擴展（硬件資源） | 開發(fā)者需要思考到底應該在應用的什么階段使用微服務架構 | |
微服務架構可以實現(xiàn)團隊自治 | ||
更容易實驗和采納新的技術 | ||
更好的容錯性（故障隔離） |
持續(xù)交付需要有DevOps配套支持，持續(xù)交付部署可以為業(yè)務帶來若干價值：縮短了產(chǎn)品的上市時間，使企業(yè)能夠快速響應客戶的反饋；使企業(yè)能夠提供當前客戶所期望的可靠服務（即業(yè)務連續(xù)性保障）；員工滿意度更高，因為開發(fā)人員可以因此花費更多時間來提供有價值的功能，而不是四處擔任救火隊員。什么是SOA
面向服務的架構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）進行拆分，并通過這些服務之間定義良好的接口和協(xié)議聯(lián)系起來。接口是采用中立的方式進行定義的，它應該獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。這使得構建在各種各樣的系統(tǒng)中的服務可以以一種統(tǒng)一和通用的方式進行交互。
對比
SOA | 微服務 | |
服務間通信 | 智能管道，例如Enterprise Service Bus(ESB也叫企業(yè)服務總線)，往往采用重量級協(xié)議，例如SOAP或其他WS*標準 | 使用啞管道，例如消息代理，或者服務之間點對點通信，使用輕量級協(xié)議，例如REST或gRPC |
數(shù)據(jù)管理 | 全局數(shù)據(jù)模型并共享數(shù)據(jù)庫 | 每個服務都有自己的數(shù)據(jù)模型和數(shù)據(jù)庫 |
典型服務的規(guī)模 | 較大的單體應用 | 較小的服務 |
總結
SOA和微服務的設計思想本質上是一致的，但是在具體實現(xiàn)上存在較大差役。SOA的技術棧通常都比較重，其主要原因也是因為它出現(xiàn)的年代比較早，當時的技術方案還比較落后。其次在數(shù)據(jù)管理層面也可以看出對于數(shù)據(jù)模型和共享上與微服務存在本質區(qū)別，SOA更注重的是應用拆分和管道管理，對于數(shù)據(jù)管理沒有投入足夠的性能或者業(yè)務連續(xù)性方面的考慮。再有就是SOA的應用往往還是比較大的，冗余程度要高于微服務，所帶來的好處就是規(guī)避了很多服務治理方面的問題。我們在設計微服務架構時，很容易由于服務拆分的不好導致最終形成類似SOA這種架構。