導(dǎo)讀：RPC壶熏，微服務(wù)句柠，Service Mesh這些服務(wù)之間的調(diào)用是什么原理？

作者 codedump codedump.info 博主久橙，多年從事互聯(lián)網(wǎng)服務(wù)器后臺(tái)開發(fā)工作俄占」艿。可訪問作者博客閱讀 codedump 更多文章淆衷。

本文專注于演化過程中每一步的為什么（Why）和是什么（What）上面，盡量不在技術(shù)細(xì)節(jié)（How）上面做太多深入渤弛。

服務(wù)的三要素

一般而言祝拯，一個(gè)網(wǎng)絡(luò)服務(wù)包括以下的三個(gè)要素：

地址：調(diào)用方根據(jù)地址訪問到網(wǎng)絡(luò)接口。地址包括以下要素：IP地址她肯、服務(wù)端口佳头、服務(wù)協(xié)議（TCP、UDP晴氨，etc）康嘉。

協(xié)議格式：協(xié)議格式指的是該協(xié)議都有哪些字段，由接口提供者與協(xié)議調(diào)用者協(xié)商之后確定下來籽前。

協(xié)議名稱：或者叫協(xié)議類型亭珍，因?yàn)樵谕粋€(gè)服務(wù)監(jiān)聽端口上面敷钾，可能同時(shí)提供多種接口服務(wù)于調(diào)用方，這時(shí)候需要協(xié)議類型（名稱）來區(qū)分不同的網(wǎng)絡(luò)接口肄梨。

需要說明在服務(wù)地址中：

IP地址提供了在互聯(lián)網(wǎng)上找到這臺(tái)機(jī)器的憑證阻荒。

協(xié)議以及服務(wù)端口提供了在這臺(tái)機(jī)器上找到提供服務(wù)的進(jìn)程的憑證。

這都屬于TCPIP協(xié)議棧的知識(shí)點(diǎn)众羡，不在這里深入詳述侨赡。

這里還需要對涉及到服務(wù)相關(guān)的一些名詞做解釋。

服務(wù)實(shí)例：服務(wù)對應(yīng)的IP地址加端口的簡稱粱侣。需要訪問服務(wù)的時(shí)候羊壹，需要先尋址知道該服務(wù)每個(gè)運(yùn)行實(shí)例的地址加端口，然后才能建立連接進(jìn)行訪問甜害。

服務(wù)注冊：某個(gè)服務(wù)實(shí)例宣稱自己提供了哪些服務(wù)舶掖，即某個(gè)IP地址+端口都提供了哪些服務(wù)接口。

服務(wù)發(fā)現(xiàn)：調(diào)用方通過某種方式找到服務(wù)提供方尔店，即知道服務(wù)運(yùn)行的IP地址加端口眨攘。

基于IP地址的調(diào)用

最初的網(wǎng)絡(luò)服務(wù)，通過原始的IP地址暴露給調(diào)用者嚣州。這種方式有以下的問題：

IP地址是難于記憶并且無意義的鲫售。

另外，從上面的服務(wù)三要素可以看到该肴，IP地址其實(shí)是一個(gè)很底層的概念情竹，直接對應(yīng)了一臺(tái)機(jī)器上的一個(gè)網(wǎng)絡(luò)接口，如果直接使用IP地址進(jìn)行尋址匀哄，更換機(jī)器就變的很麻煩秦效。

“盡量不使用過于底層的概念來提供服務(wù)”，是這個(gè)演化流程中的重要原則涎嚼，好比在今天已經(jīng)很少能夠看到直接用匯編語言編寫代碼的場景了阱州，取而代之的嚼吞，就是越來越多的抽象光酣，本文中就展現(xiàn)了服務(wù)調(diào)用這一領(lǐng)域在這個(gè)過程中的演進(jìn)流程。

在現(xiàn)在除非是測試階段敢靡，否則已經(jīng)不能直接以IP地址的形式將服務(wù)提供出去了立哑。

域名系統(tǒng)

前面的IP地址是給主機(jī)做為路由器尋址的數(shù)字型標(biāo)識(shí)夜惭，并不好記憶。此時(shí)產(chǎn)生了域名系統(tǒng)铛绰，與單純提供IP地址相比诈茧，域名系統(tǒng)由于使用有意義的域名來標(biāo)識(shí)服務(wù)，所以更容易記憶捂掰。另外敢会，還可以更改域名所對應(yīng)的IP地址镊叁，這為變換機(jī)器提供了便利。有了域名之后走触，調(diào)用方需要訪問某個(gè)網(wǎng)絡(luò)服務(wù)時(shí)晦譬，首先到域名地址服務(wù)中，根據(jù)DNS協(xié)議將域名解析為相應(yīng)的IP地址互广，再根據(jù)返回的IP地址來訪問服務(wù)敛腌。

從這里可以看到，由于多了一步到域名地址服務(wù)查詢映射IP地址的流程惫皱，所以多了一步解析像樊，為了減少這一步帶來的影響，調(diào)用方會(huì)緩存解析之后的結(jié)果旅敷，在一段時(shí)間內(nèi)不過期生棍，這樣就省去了這一步查詢的代價(jià)。

協(xié)議的接收與解析

以上通過域名系統(tǒng)媳谁，已經(jīng)解決了服務(wù)IP地址難以記憶的問題涂滴，下面來看協(xié)議格式解析方面的演進(jìn)。

一般而言晴音，一個(gè)網(wǎng)絡(luò)協(xié)議包括兩部分：

協(xié)議包頭：這里存儲(chǔ)協(xié)議的元信息（meta infomation）柔纵，其中可能會(huì)包括協(xié)議類型、報(bào)體長度锤躁、協(xié)議格式等搁料。需要說明的是，包頭一般為固定大小系羞，或者有明確的邊界（如HTTP協(xié)議中的\r\n結(jié)束符）郭计，否則無法知道包頭何時(shí)結(jié)束。

協(xié)議包體：具體的協(xié)議內(nèi)容椒振。

無論是HTTP協(xié)議昭伸，又或者是自定義的二進(jìn)制網(wǎng)絡(luò)協(xié)議，大體都由這兩部分組成杠人。

由于很多時(shí)候不能一口氣接收完畢客戶端的協(xié)議數(shù)據(jù)勋乾，因此在接收協(xié)議數(shù)據(jù)時(shí)宋下，一般采用狀態(tài)機(jī)來做協(xié)議數(shù)據(jù)的接收：

接收完畢了網(wǎng)絡(luò)數(shù)據(jù)嗡善，在協(xié)議解析方面卻長期停滯不前。一個(gè)協(xié)議学歧，有多個(gè)字段（field）罩引，而這些不同的字段有不同的類型，簡單的raw類型（如整型枝笨、字符串）還好說袁铐，但是遇到復(fù)雜的類型如字典揭蜒、數(shù)組等就比較麻煩。

當(dāng)時(shí)常見的手段有以下幾種：

使用json或者xml這樣的數(shù)據(jù)格式剔桨。好處是可視性強(qiáng)屉更，表達(dá)起上面的復(fù)雜類型也方便，缺陷是容易被破解洒缀，傳輸過去的數(shù)據(jù)較大瑰谜。

自定義二進(jìn)制協(xié)議。每個(gè)公司做大了树绩，在這一塊難免有幾個(gè)類似的輪子萨脑。筆者見過比較典型的是所謂的TLV格式（Type-Length-Value），自定義二進(jìn)制格式最大的問題出現(xiàn)在協(xié)議聯(lián)調(diào)與協(xié)商的時(shí)候饺饭，由于可視性比較弱渤早，有可能這邊少了一個(gè)字段那邊多了一個(gè)字段，給聯(lián)調(diào)流程帶來麻煩瘫俊。

上面的問題一直到Google的Protocol Buffer（以下簡稱PB）出現(xiàn)之后才得到很大的改善鹊杖。PB出現(xiàn)之后，也有很多類似的技術(shù)出現(xiàn)扛芽，如Thrift仅淑、MsgPack等，不在這里闡述胸哥，將這一類技術(shù)都以PB來描述涯竟。

與前面的兩種手段相比，PB具有以下的優(yōu)點(diǎn)：

使用proto格式文件來定義協(xié)議格式空厌，proto文件是一個(gè)典型的DSL（domain-specific language）文件庐船，文件中描述了協(xié)議的具體格式，每個(gè)字段都是什么類型嘲更，哪些是可選字段哪些是必選字段筐钟。有了proto文件之后，C\S兩端是通過這個(gè)文件來進(jìn)行協(xié)議的溝通交流的赋朦，而不是具體的技術(shù)細(xì)節(jié)篓冲。

PB能通過proto文件生成各種語言對應(yīng)的序列化反序列化代碼，給跨語言調(diào)用提供了方便宠哄。

PB自己能夠?qū)μ囟愋瓦M(jìn)行數(shù)據(jù)壓縮壹将，減少數(shù)據(jù)大小。

服務(wù)網(wǎng)關(guān)

有了前面的演化之后毛嫉，寫一個(gè)簡單的單機(jī)服務(wù)器已經(jīng)不難诽俯。然而，當(dāng)隨著訪問量的增大承粤，一臺(tái)機(jī)器已經(jīng)不足以支撐所有的請求暴区，此時(shí)就需要橫向擴(kuò)展多加一些業(yè)務(wù)服務(wù)器闯团。

而前面通過域名訪問服務(wù)的架構(gòu)就遇到了問題：如果有多個(gè)服務(wù)實(shí)例可以提供相同的服務(wù)，那么勢必需要在DNS的域名解析中將域名與多個(gè)地址進(jìn)行綁定仙粱。這樣的方案就有如下的問題：

如何檢查這些實(shí)例的健康情況房交，同時(shí)在發(fā)現(xiàn)出現(xiàn)問題的時(shí)候增刪服務(wù)實(shí)例地址？即所謂的服務(wù)高可用問題伐割。

把這些服務(wù)實(shí)例地址都暴露到外網(wǎng)涌萤，會(huì)不會(huì)涉及到安全問題？即使可以解決安全問題口猜，那么也需要每臺(tái)機(jī)器都做安全策略负溪。

由于DNS協(xié)議的特點(diǎn)，增刪服務(wù)實(shí)例并不是實(shí)時(shí)的济炎，有時(shí)候會(huì)影響到業(yè)務(wù)川抡。

為了解決這些問題，就引入了反向代理網(wǎng)關(guān)這一組件须尚。它提供如下的功能：

負(fù)載均衡功能：根據(jù)某些算法將請求分派到服務(wù)實(shí)例上崖堤。

提供管理功能，可以給運(yùn)維管理員增減服務(wù)實(shí)例耐床。

由于它決定了服務(wù)請求流量的走向密幔，因此還可以做更多的其他功能：灰度引流、安全防攻擊(如訪問黑白名單撩轰、卸載SSL證書)等胯甩。

有四層和七層負(fù)載均衡軟件，其中四層負(fù)載均衡這里介紹LVS堪嫂，七層負(fù)載均衡介紹Nginx偎箫。

上圖是簡易的TCPIP協(xié)議棧層次圖，其中LVS工作在四層皆串，即請求來到LVS這里時(shí)是根據(jù)四層協(xié)議來決定請求最終走到哪個(gè)服務(wù)實(shí)例淹办；而Nginx工作在七層，主要用于HTTP協(xié)議恶复，即根據(jù)HTTP協(xié)議本身來決定請求的走向怜森。需要說明的是，Nginx也可以工作在四層谤牡，但是這么用的地方不是很多副硅，可以參考nginx的stream模塊。

做為四層負(fù)載均衡的LVS

（由于LVS有好幾種工作模式拓哟，并不是每一種我都很清楚想许，以下表述僅針對Full NAT模式伶授，下面的表述或者有誤）

LVS有如下的組成部分：

Direct Server（以下簡稱DS）：前端暴露給客戶端進(jìn)行負(fù)載均衡的服務(wù)器断序。

Virtual Ip地址（以下簡稱VIP）：DS暴露出去的IP地址流纹，做為客戶端請求的地址。

Direct Ip地址（以下簡稱DIP）：DS用于與Real Server交互的IP地址违诗。

Real Server（以下簡稱RS）：后端真正進(jìn)行工作的服務(wù)器漱凝，可以橫向擴(kuò)展。

Real IP地址（以下簡稱RIP）：RS的地址诸迟。

Client IP地址（以下簡稱CIP）：Client的地址茸炒。

客戶端進(jìn)行請求時(shí)，流程如下：

使用VIP地址訪問DS阵苇，此時(shí)的地址二元組為<src:CIP,dst:VIP>壁公。

DS根據(jù)自己的負(fù)載均衡算法，選擇一個(gè)RS將請求轉(zhuǎn)發(fā)過去绅项，在轉(zhuǎn)發(fā)過去的時(shí)候紊册，修改請求的源IP地址為DIP地址，讓RS看上去認(rèn)為是DS在訪問它快耿，此時(shí)的地址二元組為<src:DIP,dst:RIP A>囊陡。

RS處理并且應(yīng)答該請求，這個(gè)回報(bào)的源地址為RS的RIP地址掀亥，目的地址為DIP地址撞反，此時(shí)的地址二元組為<src:RIP A,dst:DIP>。

DS在收到該應(yīng)答包之后搪花，將報(bào)文應(yīng)答客戶端遏片，此時(shí)修改應(yīng)答報(bào)文的源地址為VIP地址，目的地址為CIP地址撮竿，此時(shí)的地址二元組為<src:VIP,dst:CIP>丁稀。

做為七層負(fù)載均衡的Nginx

在開始展開討論之前，需要簡單說一下正向代理和反向代理倚聚。

所謂的正向代理（proxy）线衫，我的理解就是在客戶端處的代理。如瀏覽器中的可以配置的訪問某些網(wǎng)站的代理惑折，就屬于正向代理授账，但是一般而言不會(huì)說正向代理而是代理，即默認(rèn)代理都是正向的惨驶。

而反向代理（reverse proxy）就是擋在服務(wù)器端前面的代理白热，比如前面LVS中的DS服務(wù)器就屬于一種反向代理。為什么需要反向代理粗卜，大體的原因有以下的考量：

負(fù)載均衡：希望在這個(gè)反向代理的服務(wù)器中屋确，將請求均衡的分發(fā)到后面的服務(wù)器中。

安全：不想向客戶端暴露太多的服務(wù)器地址，統(tǒng)一接入到這個(gè)反向代理服務(wù)器中攻臀，在這里做限流焕数、安全控制等。

由于統(tǒng)一接入了客戶端的請求刨啸，所以在反向代理的接入層可以做更多的控制策略堡赔，比如灰度流量發(fā)布、權(quán)重控制等等设联。

反向代理與所謂的gateway善已、網(wǎng)關(guān)等，我認(rèn)為沒有太多的差異离例，只是叫法不同而已换团，做的事情都是類似的。

Nginx應(yīng)該是現(xiàn)在用的最多的HTTP 七層負(fù)載均衡軟件宫蛆，在Nginx中啥寇，可以通過在配置的server塊中定義一個(gè)域名，然后將該域名的請求綁定到對應(yīng)的Upstream中洒扎，而實(shí)現(xiàn)轉(zhuǎn)發(fā)請求到這些Upstream的效果辑甜。

如：

upstreamhello {serverA:11001;serverB:11001;}location/ {roothtml;indexindex.html index.htm;proxy_passhttp://hello;}

這是最簡單的Nginx反向代理配置，實(shí)際線上一個(gè)接入層背后可能有多個(gè)域名袍冷，如果配置變動(dòng)的很大磷醋，每次域名以及對應(yīng)的Upstream的配置修改都需要人工干預(yù)，效率會(huì)很慢胡诗。這時(shí)候就要提到一個(gè)叫DevOps的名詞了邓线，我的理解就是開發(fā)各種便于自動(dòng)化運(yùn)維工具的工程師。

有了上面的分析煌恢，此時(shí)一個(gè)提供七層HTTP訪問接口的服務(wù)架構(gòu)大體是這樣的：

服務(wù)發(fā)現(xiàn)與RPC

前面已經(jīng)解決單機(jī)服務(wù)器對外提供服務(wù)的大部分問題骇陈，來簡單回顧：

域名系統(tǒng)解決了需要記住復(fù)雜的數(shù)字IP地址的問題。

PB類軟件庫的出現(xiàn)解決協(xié)議定義解析的痛點(diǎn)瑰抵。

網(wǎng)關(guān)類組件解決客戶端接入以及服務(wù)器橫向擴(kuò)展等一系列問題你雌。

然而一個(gè)服務(wù)，通常并不見得只由本身提供服務(wù)就可以二汛，服務(wù)過程中可能還涉及到查詢其他服務(wù)的流程婿崭，常見的如數(shù)據(jù)類服務(wù)如Mysql、Redis等肴颊，這一類供服務(wù)內(nèi)調(diào)用查詢的服務(wù)被成為內(nèi)部的服務(wù)氓栈，通常并不直接暴露到外網(wǎng)去。

面向公網(wǎng)的服務(wù)婿着，一般都是以域名的形式提供給外部調(diào)用者授瘦，然而對于服務(wù)內(nèi)部之間的互相調(diào)用醋界，域名形式還不夠，其原因在于：

DNS服務(wù)發(fā)現(xiàn)的粒度太粗提完，只能到IP地址級(jí)別形纺，而服務(wù)的端口還需要用戶自己維護(hù)。

對于服務(wù)的健康狀況的檢查氯葬，DNS的檢查還不夠挡篓，需要運(yùn)維的參與婉陷。

DNS對于服務(wù)狀態(tài)的收集很欠缺帚称，而服務(wù)狀態(tài)最終應(yīng)該是反過來影響服務(wù)被調(diào)用情況的。

DNS的變更需要人工的參與秽澳，不夠智能以及自動(dòng)化闯睹。

綜上，內(nèi)網(wǎng)間的服務(wù)調(diào)用担神，通常而言會(huì)自己實(shí)現(xiàn)一套“服務(wù)發(fā)現(xiàn)”類的系統(tǒng)楼吃，其包括以下幾個(gè)組件：

服務(wù)發(fā)現(xiàn)系統(tǒng)：用于提供服務(wù)的尋址、注冊能力妄讯，以及對服務(wù)狀態(tài)進(jìn)行統(tǒng)計(jì)匯總孩锡，根據(jù)服務(wù)情況更改服務(wù)的調(diào)用情況。比如亥贸，某個(gè)服務(wù)實(shí)例的響應(yīng)慢了躬窜，此時(shí)分配給該實(shí)例的流量響應(yīng)的就會(huì)少一些。而由于這個(gè)系統(tǒng)能提供服務(wù)的尋址能力炕置，所以一些尋址策略就可以在這里做荣挨，比如灰度某些特定的流量只能到某些特定的實(shí)例上，比如可以配置每個(gè)實(shí)例的流量權(quán)重等朴摊。

一套與該服務(wù)系統(tǒng)搭配使用的RPC庫默垄，其提供以下功能：

服務(wù)提供方：使用RPC庫注冊自己的服務(wù)到服務(wù)發(fā)現(xiàn)系統(tǒng)，另外上報(bào)自己的服務(wù)情況甚纲。

服務(wù)調(diào)用方：使用RPC庫進(jìn)行服務(wù)尋址口锭，實(shí)時(shí)從服務(wù)發(fā)現(xiàn)系統(tǒng)那邊獲取最新的服務(wù)調(diào)度策略。

提供協(xié)議的序列化介杆、反序列化功能讹弯，負(fù)載均衡的調(diào)用策略、熔斷限流等安全訪問策略这溅，這部分對于服務(wù)的提供方以及調(diào)用方都適用组民。

有了這套服務(wù)發(fā)現(xiàn)系統(tǒng)以及搭配使用的RPC庫之后，來看看現(xiàn)在的服務(wù)調(diào)用是什么樣的悲靴。

寫業(yè)務(wù)邏輯的臭胜，再也不用關(guān)注服務(wù)地址莫其、協(xié)議解析、服務(wù)調(diào)度耸三、自身服務(wù)情況上報(bào)等等與業(yè)務(wù)邏輯本身并沒有太多關(guān)系的工作乱陡，專注于業(yè)務(wù)邏輯即可。

服務(wù)發(fā)現(xiàn)系統(tǒng)一般還有與之搭配的管理后臺(tái)界面仪壮，可以通過這里對服務(wù)的策略進(jìn)行修改查看等操作憨颠。

對應(yīng)的還會(huì)有服務(wù)監(jiān)控系統(tǒng)，對應(yīng)的這是一臺(tái)實(shí)時(shí)采集服務(wù)數(shù)據(jù)進(jìn)行計(jì)算的系統(tǒng)积锅，有了這套系統(tǒng)服務(wù)質(zhì)量如何一目了然爽彤。

服務(wù)健康狀態(tài)的檢查完全自動(dòng)化，在狀況不好的時(shí)候?qū)Ψ?wù)進(jìn)行降級(jí)處理缚陷，人工干預(yù)變少适篙，更加智能以及自動(dòng)化。

現(xiàn)在服務(wù)的架構(gòu)又演進(jìn)成了這樣：

ServiceMesh

架構(gòu)發(fā)展到上面的程度箫爷，實(shí)際上已經(jīng)能夠解決大部分的問題了嚷节。這兩年又出現(xiàn)了一個(gè)很火的概念：ServiceMesh，中文翻譯為“服務(wù)網(wǎng)格”虎锚，來看看它又能解決什么問題硫痰。

前面的服務(wù)發(fā)現(xiàn)系統(tǒng)中，需要一個(gè)與之配套的RPC庫窜护，然而這又會(huì)有如下的問題：

如果需要支持多語言效斑，該怎么做？每個(gè)語言實(shí)現(xiàn)一個(gè)對應(yīng)的RPC庫嗎柄慰？

庫的升級(jí)很麻煩鳍悠，比如RPC庫本身出了安全漏洞，比如需要升級(jí)版本坐搔，一般推動(dòng)業(yè)務(wù)方去做這個(gè)升級(jí)是很難的藏研，尤其是系統(tǒng)做大了之后。

可以看到概行，由于RPC庫是嵌入到進(jìn)程之中的組件蠢挡，所以以上問題很麻煩，于是就想出了一個(gè)辦法：將原先的一個(gè)進(jìn)程拆分成兩個(gè)進(jìn)程凳忙，如下圖所示业踏。

在服務(wù)mesh化之前，服務(wù)調(diào)用方實(shí)例通過自己內(nèi)部的RPC庫來與服務(wù)提供方實(shí)例進(jìn)行通信涧卵。

在服務(wù)mesh化之后勤家，會(huì)與服務(wù)調(diào)用方同機(jī)部署一個(gè)local Proxy也就是ServiceMesh的proxy，此時(shí)服務(wù)調(diào)用的流量會(huì)先走到這個(gè)proxy柳恐，再由它完成原先RPC庫響應(yīng)的工作伐脖。至于如何實(shí)現(xiàn)這個(gè)流量的劫持热幔，答案是采用iptables，將特定端口的流量轉(zhuǎn)發(fā)到proxy上面即可讼庇。

有了這一層的分拆绎巨，將業(yè)務(wù)服務(wù)與負(fù)責(zé)RPC庫作用的Proxy分開來，上面的兩個(gè)痛點(diǎn)問題就變成了對每臺(tái)物理機(jī)上面的mesh proxy的升級(jí)維護(hù)問題蠕啄，多語言也不是問題了场勤，因?yàn)槎际峭ㄟ^網(wǎng)絡(luò)調(diào)用完成的RPC通信，而不是進(jìn)程內(nèi)使用RPC庫歼跟。

然而這個(gè)方案并不是什么問題都沒有的和媳，最大的問題在于，多了這一層的調(diào)用之后嘹承，勢必有影響原來的響應(yīng)時(shí)間窗价。

截止目前（2019.6月）如庭，ServiceMesh仍然還是一個(gè)概念大于實(shí)際的產(chǎn)品叹卷。

從上面的演進(jìn)歷史可以看到，所謂的“中間層理論”坪它，即“Any problem in computer science can be solved by another layer of indirection（計(jì)算機(jī)科學(xué)領(lǐng)域的任何問題都可以通過增加一個(gè)間接的中間層來解決）”在這個(gè)過程中被廣泛使用骤竹，比如為了解決IP地址難于記憶的問題，引入了域名系統(tǒng)往毡，比如為了解決負(fù)載均衡問題引入了網(wǎng)關(guān)蒙揣，等等。然而每引入一個(gè)中間層开瞭，勢必帶來另外的影響懒震，比如ServiceMesh多一次到Proxy的調(diào)用，如何權(quán)衡又是另外的問題了嗤详。

另外个扰，回到最開始的服務(wù)三要素中，可以看到整個(gè)演化的歷史也是逐漸屏蔽了下層組件的流程葱色，比如：

域名的出現(xiàn)屏蔽了IP地址递宅。

服務(wù)發(fā)現(xiàn)系統(tǒng)屏蔽協(xié)議及端口號(hào)。

PB類序列化庫屏蔽了使用者自己對協(xié)議的解析苍狰。

可以看到办龄，演進(jìn)流程讓業(yè)務(wù)開發(fā)者更加專注在業(yè)務(wù)邏輯上，這類的演進(jìn)流程不只發(fā)生在今天淋昭，也不會(huì)僅僅發(fā)生在今天俐填，未來類似的演進(jìn)也將再次發(fā)生。