[[414950]]

整體發展概覽

服務架構一直處于演變之中，為了適合自己的業務，不斷的去調整。

整體的發展歷程如下：

開發者視角

從一個 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 微服務

挑戰

微服務的挑戰可以概述如下：

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

不過幸運的是，很多成熟的中間件，已經為我們解決了這些問題。

第一代微服務框架

dubbo 的架構

Dubbo 的架構如下：

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

但是為什么還是會這么火爆呢?

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

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

如果你們公司是全新的技術選型，可以考慮 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 年，就會被徹底淘汰。

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