[[414950]]

整體發(fā)展概覽

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

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

開發(fā)者視角

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

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

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

這個(gè)也就是老馬剛畢業(yè)時(shí)候的架構(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ù)雜度，于是對(duì)系統(tǒng)模塊進(jìn)行拆解，分不到不同的系統(tǒng)中，降低模塊耦合，加快迭代速度。

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

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

但是用起來感覺不是很順暢，主要缺點(diǎn)如下：

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

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

后來逐漸演變?yōu)榱爽F(xiàn)在的 MSA(Micro-Service Archeticture 微服務(wù)架構(gòu))，從而實(shí)現(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é)議是輕量級(jí)的。

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

優(yōu)點(diǎn)

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

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

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

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

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

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

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

缺點(diǎn)

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

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

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

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

SOA vs 微服務(wù)

挑戰(zhàn)

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

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

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

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

dubbo 的架構(gòu)

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

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

但是為什么還是會(huì)這么火爆呢?

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

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

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

spring cloud 架構(gòu)

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

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

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

推薦閱讀：

Microservice Architectures With Spring Cloud and Docker

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

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

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

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

個(gè)人感悟

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

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

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

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

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