技術架構的演進之路： 爲何須要微服務？

總體發展概覽

服務架構一直處於演變之中，爲了適合本身的業務，不斷的去調整。

總體的發展歷程以下：

開發者視角

從一個 java 開發者，感覺大概經歷了下面幾個歷程：

第一階段：單體架構

早期，大部分IT系統都是單體系統，例如傳統的SSH架構，此時先後端也沒有分離，UI組件也包含在了控制層：

這個也就是老馬剛畢業時候的架構，SSH 基本是面試必問。

不過如今這些都發生了一些變化，主流已經變成了 spring mvc + spring contaienr + mybatis。

只能說，spring，java 界永遠的春天！

第二階段：分佈式架構

爲了方便給系統擴容，以及增長系統的複用性，出現分佈式系統。

另外一方面，系統模塊快速膨脹，爲了下降系統內部的複雜度，因而對系統模塊進行拆解，分不到不一樣的系統中，下降模塊耦合，加快迭代速度。

ps: 其實主要是下降單個應用的複雜性，讓每個應用專一於一件事情。這樣可維護成本大大下降，換言之，開發完後之後，可讓一個剛畢業的新人作運維。把開發者裁掉，下降成本。

主流主要是 SOA 和 MSA 兩種體系。

SOA

早期的分佈式系統是基於面向服務的架構SOA。

SOA是微服務的前身，主要是爲了擺脫單體應用的問題，達到如下效果：

1. 充分利用現有的基礎設施；
2. SOA體系結構依賴於消息傳遞（AMQP，MSMQ）和SOAP做爲主要的遠程訪問協議。
3. 快速響應業務變化；

架構圖以下：

異構系統，也能夠經過消息中間件的協議轉換進行相互調用。

這個我卻是接觸過一段時間，當時業務系統是 C# 開發，我所在的後端服務使用的是 java 技術開發。當時的協議使用的是 webservice。

可是用起來感受不是很順暢，主要缺點以下：

（1）WebService中經常使用的SOAP通訊協議，一般使用XML格式進行通訊，數據冗餘，協議太重

（2）服務治理很不完善。

後來逐漸演變爲了如今的 MSA（Micro-Service Archeticture 微服務架構），從而實現了更加鬆耦合以及更加靈活的系統。

MSA

微服務是一種軟件開發技術——面向服務的體系結構(SOA)體系結構樣式的變體，它將應用程序構造爲鬆散耦合服務的集合。

在微服務體系結構中，服務是細粒度的，協議是輕量級的。

• 微服務架構圖示

優勢

微服務架構有不少重要的優勢。

首先，它解決了複雜性問題。它將單體應用分解爲一組服務。雖然功能總量不變，但應用程序已被分解爲可管理的模塊或服務。

這些服務定義了明確的RPC或消息驅動的API邊界。微服務架構強化了應用模塊化的水平，而這經過單體代碼庫很難實現。

所以，微服務開發的速度要快不少，更容易理解和維護。

第三，微服務架構可使每一個微服務獨立部署。

最後，微服務架構使得每一個服務均可獨立擴展。

如今這種架構模式已經成爲主流，我的感覺最深的就是若是你只負責單一服務，你能夠把他理解的比較透徹，並且維護起來也沒有那麼複雜。若是有功能變動，只上線對應的應用便可。

缺點

微服務的一些想法在實踐上是好的，但當總體實現時也會呈現出其複雜性。

• 運維開銷及成本增長
• 必須有堅實的 DevOps 開發運維一體化技能
• 隱式接口及接口匹配問題
• 代碼重複
• 分佈式系統的複雜性
• 異步機制
• 可測性的挑戰

我的感受微服務最大的問題在於系統的拆分以後，很難有一我的能夠知道系統的全貌，因此定位問題變得很是複雜。

舉個例子，若是交易發生一筆失敗，你可能要從API網關=》業務系統=》交易核心=》支付核心=》風控系統問一遍才能知道緣由，最後發現是對底層的系統返回了一個失敗，這裏涉及到多個系統的溝通成本，基本上半天的時間就沒了。

SOA vs 微服務

SOA	微服務架構
應用程序服務的可重用性的最大化	專一於解耦
系統性的改變須要修改總體	系統性的改變是建立一個新的服務
DevOps和持續交付正在變得流行，但還不是主流	強烈關注DevOps和持續交付
專一於業務功能重用	更重視「上下文邊界」的概念
通訊使用企業服務總線ESB	對於通訊而言，使用較少精細和簡單的消息系統
支持多種消息協議	使用輕量級協議，例如HTTP，REST或Thrift API
對部署到它的全部服務使用通用平臺	應用程序服務器不是真的被使用，一般使用雲平臺
容器（如Docker）的使用不太受歡迎	容器在微服務方面效果很好
SOA服務共享數據存儲	每一個微服務能夠有一個獨立的數據存儲
共同的治理和標準	輕鬆的治理，更加關注團隊協做和選擇自由

挑戰

微服務的挑戰能夠概述以下：

• API Gateway
• 服務間調用
• 服務發現
• 服務容錯
• 服務部署
• 數據調用

不過幸運的是，不少成熟的中間件，已經爲咱們解決了這些問題。

第一代微服務框架

dubbo 的架構

Dubbo 的架構以下：

dubbo 針對 rpc 這部分作的很好，單也僅此而已。

可是爲何仍是會這麼火爆呢？

不少架構的升級都會有歷史包袱，除非你是一家新公司，全新的應用。

大部分的應用都是 spring 或者 springboot 的，因此如今大部分公司都是 springboot + dubbo 的技術選型方案，這樣可讓架構的平滑的遷移。

若是大家公司是全新的技術選型，能夠考慮 spring cloud。

spring cloud 架構

Spring Cloud 架構以下：

你會發現 spring cloud 能夠說是 java 技術棧中，比較完善的微服務框架。

固然，spring 再牛，負責的聲明週期也只是 jvm 以內，應用的部署運維也是須要考慮的。

每一項技術都有其優點和侷限性，因此須要結合使用。

推薦閱讀：

Microservice Architectures With Spring Cloud and Docker

目前 docker 虛擬化技術如日中天，結合 k8s 掌託。

我選稱這盛世爲，喝不起咖啡的打工人，在春天的貨船上，996 搬磚！

下一代微服務：Service Mesh？

Service Mesh 也是目前比較火爆的技術，咱們後續進行詳解。

我的感悟

技術架構的演進和生物的進化是相似的，物競天擇，適者生存。

學習技術也不能只侷限於如今這一刻，要學會去回顧技術的歷史，知道爲何是這樣？若是有能力，也能夠引領技術的將來，爲何不是這樣呢？

我以爲本身很幸運，最初接觸的是單體應用，是 spring xml 配置的時代。

我以爲本身很不幸，框架層出不窮，技術突飛猛進，若是不持續學習，不出 5 年，就會被完全淘汰。

爲了避免被那麼快淘汰，本系列將從微服務的發展歷史，理論知識，入門使用，應用實戰，實現原理，重複造輪子等方面，逐漸理解微服務。

我是老馬，期待與你，一塊兒見證開發者的春天！