[[414950]]

整體發(fā)展概覽

服務(wù)架構(gòu)一直處于演變之中，為了適合自己的業(yè)務(wù)，不斷的去調(diào)整。

整體的發(fā)展歷程如下：

開發(fā)者視角

從一個 java 開發(fā)者，感受大概經(jīng)歷了下面幾個歷程：

第一階段：單體架構(gòu)

早期，大部分IT系統(tǒng)都是單體系統(tǒng)，例如傳統(tǒng)的SSH架構(gòu)，此時前后端也沒有分離，UI組件也包含在了控制層：

這個也就是老馬剛畢業(yè)時候的架構(gòu)，SSH 基本是面試必問。

不過現(xiàn)在這些都發(fā)生了一些變化，主流已經(jīng)變成了 spring mvc + spring contaienr + mybatis。

只能說，spring，java 界永遠(yuǎn)的春天!

第二階段：分布式架構(gòu)

為了方便給系統(tǒng)擴(kuò)容，以及增加系統(tǒng)的復(fù)用性，出現(xiàn)分布式系統(tǒng)。

另一方面，系統(tǒng)模塊快速膨脹，為了降低系統(tǒng)內(nèi)部的復(fù)雜度，于是對系統(tǒng)模塊進(jìn)行拆解，分不到不同的系統(tǒng)中，降低模塊耦合，加快迭代速度。

ps: 其實主要是降低單個應(yīng)用的復(fù)雜性，讓每一個應(yīng)用專注于一件事情。這樣可維護(hù)成本大大降低，換言之，開發(fā)完后以后，可以讓一個剛畢業(yè)的新人做運維。把開發(fā)者裁掉，降低成本。

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

SOA

早期的分布式系統(tǒng)是基于面向服務(wù)的架構(gòu)SOA。

SOA是微服務(wù)的前身，主要是為了擺脫單體應(yīng)用的問題，達(dá)到以下效果：

1. 充分利用現(xiàn)有的基礎(chǔ)設(shè)施;
2. SOA體系結(jié)構(gòu)依賴于消息傳遞(AMQP，MSMQ)和SOAP作為主要的遠(yuǎn)程訪問協(xié)議。
3. 快速響應(yīng)業(yè)務(wù)變化;

架構(gòu)圖如下：

異構(gòu)系統(tǒng)，也可以通過消息中間件的協(xié)議轉(zhuǎn)換進(jìn)行相互調(diào)用。

這個我倒是接觸過一段時間，當(dāng)時業(yè)務(wù)系統(tǒng)是 C# 開發(fā)，我所在的后端服務(wù)使用的是 java 技術(shù)開發(fā)。當(dāng)時的協(xié)議使用的是 webservice。

但是用起來感覺不是很順暢，主要缺點如下：

(1)WebService中常用的SOAP通信協(xié)議，通常使用XML格式進(jìn)行通信，數(shù)據(jù)冗余，協(xié)議過重

(2)服務(wù)治理很不完善。

后來逐漸演變?yōu)榱爽F(xiàn)在的 MSA(Micro-Service Archeticture 微服務(wù)架構(gòu))，從而實現(xiàn)了更加松耦合以及更加靈活的系統(tǒng)。

MSA

微服務(wù)是一種軟件開發(fā)技術(shù)——面向服務(wù)的體系結(jié)構(gòu)(SOA)體系結(jié)構(gòu)樣式的變體，它將應(yīng)用程序構(gòu)造為松散耦合服務(wù)的集合。

在微服務(wù)體系結(jié)構(gòu)中，服務(wù)是細(xì)粒度的，協(xié)議是輕量級的。

微服務(wù)架構(gòu)圖示

優(yōu)點

微服務(wù)架構(gòu)有很多重要的優(yōu)點。

首先，它解決了復(fù)雜性問題。它將單體應(yīng)用分解為一組服務(wù)。雖然功能總量不變，但應(yīng)用程序已被分解為可管理的模塊或服務(wù)。

這些服務(wù)定義了明確的RPC或消息驅(qū)動的API邊界。微服務(wù)架構(gòu)強(qiáng)化了應(yīng)用模塊化的水平，而這通過單體代碼庫很難實現(xiàn)。

因此，微服務(wù)開發(fā)的速度要快很多，更容易理解和維護(hù)。

第三，微服務(wù)架構(gòu)可以使每個微服務(wù)獨立部署。

最后，微服務(wù)架構(gòu)使得每個服務(wù)都可獨立擴(kuò)展。

現(xiàn)在這種架構(gòu)模式已經(jīng)成為主流，個人感受最深的就是如果你只負(fù)責(zé)單一服務(wù)，你可以把他理解的比較透徹，而且維護(hù)起來也沒有那么復(fù)雜。如果有功能變更，只上線對應(yīng)的應(yīng)用即可。

缺點

微服務(wù)的一些想法在實踐上是好的，但當(dāng)整體實現(xiàn)時也會呈現(xiàn)出其復(fù)雜性。

• 運維開銷及成本增加
• 必須有堅實的 DevOps 開發(fā)運維一體化技能
• 隱式接口及接口匹配問題
• 代碼重復(fù)
• 分布式系統(tǒng)的復(fù)雜性
• 異步機(jī)制
• 可測性的挑戰(zhàn)

個人感覺微服務(wù)最大的問題在于系統(tǒng)的拆分之后，很難有一個人可以知道系統(tǒng)的全貌，所以定位問題變得非常復(fù)雜。

舉個例子，如果交易發(fā)生一筆失敗，你可能要從API網(wǎng)關(guān)=》業(yè)務(wù)系統(tǒng)=》交易核心=》支付核心=》風(fēng)控系統(tǒng)問一遍才能知道原因，最后發(fā)現(xiàn)是對底層的系統(tǒng)返回了一個失敗，這里涉及到多個系統(tǒng)的溝通成本，基本上半天的時間就沒了。

SOA vs 微服務(wù)

挑戰(zhàn)

微服務(wù)的挑戰(zhàn)可以概述如下：

• API Gateway
• 服務(wù)間調(diào)用
• 服務(wù)發(fā)現(xiàn)
• 服務(wù)容錯
• 服務(wù)部署
• 數(shù)據(jù)調(diào)用

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

第一代微服務(wù)框架

dubbo 的架構(gòu)

Dubbo 的架構(gòu)如下：

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

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

很多架構(gòu)的升級都會有歷史包袱，除非你是一家新公司，全新的應(yīng)用。

大部分的應(yīng)用都是 spring 或者 springboot 的，所以現(xiàn)在大部分公司都是 springboot + dubbo 的技術(shù)選型方案，這樣可以讓架構(gòu)的平滑的遷移。

如果你們公司是全新的技術(shù)選型，可以考慮 spring cloud。

spring cloud 架構(gòu)

你會發(fā)現(xiàn) spring cloud 可以說是 java 技術(shù)棧中，比較完善的微服務(wù)框架。

當(dāng)然，spring 再牛，負(fù)責(zé)的聲明周期也只是 jvm 之內(nèi)，應(yīng)用的部署運維也是需要考慮的。

每一項技術(shù)都有其優(yōu)勢和局限性，所以需要結(jié)合使用。

推薦閱讀：

Microservice Architectures With Spring Cloud and Docker

目前 docker 虛擬化技術(shù)如日中天，結(jié)合 k8s 掌托。

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

下一代微服務(wù)：Service Mesh?

Service Mesh 也是目前比較火爆的技術(shù)，我們后續(xù)進(jìn)行詳解。

個人感悟

技術(shù)架構(gòu)的演進(jìn)和生物的進(jìn)化是類似的，物競天擇，適者生存。

學(xué)習(xí)技術(shù)也不能只局限于現(xiàn)在這一刻，要學(xué)會去回顧技術(shù)的歷史，知道為什么是這樣?如果有能力，也可以引領(lǐng)技術(shù)的未來，為什么不是這樣呢?

我覺得自己很幸運，最初接觸的是單體應(yīng)用，是 spring xml 配置的時代。

我覺得自己很不幸，框架層出不窮，技術(shù)日新月異，如果不持續(xù)學(xué)習(xí)，不出 5 年，就會被徹底淘汰。

為了不被那么快淘汰，本系列將從微服務(wù)的發(fā)展歷史，理論知識，入門使用，應(yīng)用實戰(zhàn)，實現(xiàn)原理，重復(fù)造輪子等方面，逐漸理解微服務(wù)。