【51CTO.com原創(chuàng)稿件】微服務(wù)是一個(gè)比較大的話題，基于我的過往經(jīng)歷，本文將以 Netflix 為例，分享一個(gè)大型互聯(lián)網(wǎng)公司如何從一個(gè) Monolithic 的 APP 成功轉(zhuǎn)型到微服務(wù)。文章主要涉及微服務(wù)的產(chǎn)生歷史，應(yīng)用場景，與單片服務(wù)區(qū)別，微服務(wù)帶來的技術(shù)、企業(yè)組織結(jié)構(gòu)等方面挑戰(zhàn)，以及如何合理地選擇單片服務(wù)構(gòu)架和微服務(wù)構(gòu)架等內(nèi)容。

微服務(wù)的產(chǎn)生歷史

如下圖，是微服務(wù)在 Google 的搜索結(jié)果：

自 2014 年以來，微服務(wù)開始被關(guān)注，搜索的人越來越多，并在 2016 年左右達(dá)到頂峰。從地域來看，很多國家都在關(guān)注，如印度，歐洲等等，并且很多公司在使用微服務(wù)構(gòu)架。以下以 Netflix 為例來分享微服務(wù)的演變過程以及帶來的挑戰(zhàn)。

Netflix 的微服務(wù)演化

我 2012 年加入Netflix，從中了解到：

•     Netflix 從 2008 到 2009 年就開始在自有數(shù)據(jù)中心做單片的 Web 應(yīng)用，那個(gè)時(shí)期是很龐大的 Java 包，無數(shù)的程序?qū)懺谄渲校斐珊芏鄦栴}。
•     2010 年開始把重量級(jí)的部分轉(zhuǎn)出。
•     2013 到 2014 年，其他的模塊也陸續(xù)轉(zhuǎn)出，并發(fā)布很多 Open Source 的微服務(wù)工具，在硅谷及全球受到很多人的關(guān)注。
•     直至 2015 年左右，Netflix 基本完成向微服務(wù)的轉(zhuǎn)型，也徹底從自有數(shù)據(jù)中心，轉(zhuǎn)移到亞馬遜的云平臺(tái)。

如下，是微服務(wù)示意圖：

微服務(wù)看上去很復(fù)雜，其實(shí)它是一個(gè)個(gè)服務(wù)器組成的，這些服務(wù)器之間相互連接。

如下圖，是 Netflix 在微服務(wù)方面的使用情況：

從時(shí)間點(diǎn)看，Netflix 是硅谷采用微服務(wù)比較早的公司，在采用過程中也受到很多質(zhì)疑，特別是傳統(tǒng)公司，從數(shù)據(jù)中心遷到云上，需要時(shí)間來慢慢接受。

微服務(wù)、單片服務(wù)兩者的概念與區(qū)別

如下，是很普遍的 Monolithic APP 示意圖：

從 powser 到各種公司的 Apache，形成一個(gè)包含各種功能的 WAR 包，最后是一個(gè) MySQL 的存儲(chǔ)層。這樣的方式，比較易于測試，部署方面也很簡單。

Monolithic APP 的優(yōu)點(diǎn)如下：

•     易于開發(fā)。很多 IDE 和框架都支持，比如 Sprint MVC、Ruby Rails、Python Django 等。
•     易于測試?？梢酝ㄟ^簡單啟動(dòng)應(yīng)用程序并使用 Selenium 測試 UI 來實(shí)現(xiàn)端到端測試。
•     易于部署。只需將打包的應(yīng)用程序復(fù)制到服務(wù)器。
•     易于擴(kuò)展。通過在負(fù)載平衡器后運(yùn)行多個(gè)副本，可以輕松地水平擴(kuò)展。
•     DevOps 比較簡單。一支專門 DevOps 團(tuán)隊(duì)負(fù)責(zé)即可。

Monolithic APP 的缺點(diǎn)如下：

•     應(yīng)用程序太大且復(fù)雜，很難完全理解并快速正確地進(jìn)行更改。
•     應(yīng)用程序會(huì)越變?cè)酱?，可能?huì)減慢啟動(dòng)時(shí)間。
•     必須在每次更新時(shí)重新部署整個(gè)應(yīng)用程序。
•     如果代碼庫有新的變化，變化的影響通常不是很清楚，這導(dǎo)致廣泛的手動(dòng)測試。
•     連續(xù)部署很困難。
•     當(dāng)不同模塊具有沖突的資源需求時(shí)，單片應(yīng)用也可能難以擴(kuò)展。
•     可靠性差。任何模塊中的錯(cuò)誤（例如內(nèi)存泄漏）都可能會(huì)導(dǎo)致整個(gè)網(wǎng)站宕機(jī)。此外，由于應(yīng)用程序的所有實(shí)例是相同的，該錯(cuò)誤將影響整個(gè)應(yīng)用程序的可用性。
•     采用新技術(shù)或框架很困難。由于框架或語言的變化將影響整個(gè)應(yīng)用程序，因此在時(shí)間和成本上都是非常昂貴的。

隨著代碼庫，組件和團(tuán)隊(duì)規(guī)模增長，各種問題相繼出現(xiàn)。

主要概括為如下幾點(diǎn)：

•     原代碼太大，IDE 打不開了。
•     單機(jī)的內(nèi)存不夠，沒法編譯和跑代碼。
•     部署一次要花很長時(shí)間。
•     開發(fā)速度跟不上產(chǎn)品的需求，一個(gè)小小的變化需要整個(gè)源代碼重新編譯。
•     某一個(gè)模塊里的一個(gè)小錯(cuò)誤，可能導(dǎo)致整個(gè)網(wǎng)站宕機(jī)。

隨著組織的成長，功能的增多以及技術(shù)棧的瓶頸出現(xiàn)，需要有新的變革。但面對(duì)如此龐大的視頻網(wǎng)站，有的程序都是用的 Java 包，自有數(shù)據(jù)中心，當(dāng)時(shí)還沒有微服務(wù)的概念，但已經(jīng)有了把內(nèi)容拆分出來的意識(shí)。

什么是微服務(wù)？

“微”是指團(tuán)隊(duì)、代碼行數(shù)或 API 端口的數(shù)目等指標(biāo)的大小？都不是，不同人對(duì)微服務(wù)有不同定義。

個(gè)人比較贊同這個(gè)描述：Loosely coupled service orientedarchitecture with bounded contexts。

關(guān)鍵是 LOOSELY  COUPLED和BOUNDED TEXT，LOOSELY  COUPLED 意味著每個(gè)服務(wù)可以獨(dú)立更新，BOUNDED TEXT 意味著一個(gè)服務(wù)只要做自己的事情，外界以API等接口。

也就是微服務(wù)要實(shí)現(xiàn)獨(dú)立部署，擁有獨(dú)立技術(shù)棧、界定上下文，明確的所有權(quán)等特點(diǎn)。

微服務(wù)與單片服務(wù)的對(duì)比

如下，是微服務(wù)與單片服務(wù)很形象的對(duì)比圖：

單片服務(wù)是把所有的東西放在一個(gè)大盒子里，這個(gè)大盒子里什么都有。微服務(wù)更像是車箱，每個(gè)箱子里包含特定的功能模塊和物品，所有東西可以很靈活地拆分出來。

也就是說，在 Monolithic APP 中，所有的部件都在一個(gè)巨大的軟件包中。在微服務(wù)的構(gòu)建下，有很多獨(dú)立存在的小服務(wù)，通過 API 接口連接成大的系統(tǒng)。

如下圖，是 Monolithic APP 的架構(gòu)：

Netflix 會(huì)支撐很多設(shè)備，最初是所有設(shè)備通過一個(gè)負(fù)載均衡器到一個(gè)碩大的、什么都包含的程序中，最后會(huì)成為一個(gè)碩大的 Oracle 數(shù)據(jù)中心。這樣一來，會(huì)產(chǎn)生很大問題，大家都很反感。

如下圖，是微服務(wù)的架構(gòu)：

上圖可以看出每個(gè)服務(wù)都可拆分，自有數(shù)據(jù)源，不一定是 Oracle，可根據(jù)業(yè)務(wù)場景用不同的數(shù)據(jù)庫，完全由各個(gè)團(tuán)隊(duì)自己決定。

綜上是從技術(shù)角度分析 Netflix 為什么選擇微服務(wù)，從商業(yè)角度來看 Netflix 選擇微服務(wù)的原因如下。

有三點(diǎn)原因：

•     可用性(Availability)。24 x 7 防止單點(diǎn)失?。╯ingle point of failure）。在巨大的 CODEBASE 情況下，經(jīng)常一個(gè)小小的錯(cuò)誤比如代碼中多加了一個(gè)冒號(hào)就會(huì)導(dǎo)致整個(gè)程序編譯不了甚至引起整個(gè)網(wǎng)站宕機(jī)。對(duì)于大型互聯(lián)網(wǎng)公司而言，一定要避免單片服務(wù)導(dǎo)致的宕機(jī)。
•     可拓展性。Netflix 當(dāng)時(shí)流量占到美國三分之一，超過 9000W 的付費(fèi)用戶且增長非常快。一旦某部件達(dá)到瓶頸時(shí)要有迅速可拓展的能力，一般就是添加新機(jī)器讓它運(yùn)轉(zhuǎn)。但在傳統(tǒng)單片服務(wù)上，整個(gè)部分綁定在一起，擴(kuò)展非常困難。
•      速度。對(duì)互聯(lián)網(wǎng)公司，特別是 ToC 需要快速推出，速度很重要。速度在互聯(lián)網(wǎng)時(shí)代是致勝的關(guān)鍵。
•     大型互聯(lián)網(wǎng)公司推行微服務(wù)，一旦需要新功能，可立即新開一個(gè)微服務(wù)，或在幾個(gè)有限的微服務(wù)中進(jìn)行改動(dòng)，不需要像原來基于巨大的數(shù)據(jù)庫來改動(dòng)。

微服務(wù)帶來的技術(shù)挑戰(zhàn)

軟件構(gòu)架從單片服務(wù)向微服務(wù)轉(zhuǎn)型過程中帶來了很大的技術(shù)挑戰(zhàn)。下面選取自認(rèn)為比較關(guān)鍵的內(nèi)容進(jìn)行分享。

主要涉及以下幾方面的挑戰(zhàn)：

•     服務(wù)發(fā)現(xiàn)(Service discovery)。傳統(tǒng)單片服務(wù)相對(duì)簡單，但微服務(wù)有幾百上千的服務(wù)器，對(duì)用戶來講，服務(wù)器的選擇是個(gè)問題。
•     運(yùn)維復(fù)雜度增加 – DevOps。
•     分布式系統(tǒng)本質(zhì)上帶來的復(fù)雜度。
•     網(wǎng)絡(luò)延遲，容錯(cuò)。
•     服務(wù)接口版本控制，存在不匹配。
•     測試（需要整個(gè)生態(tài)系統(tǒng)來測試）。
•     FAN OUT - >增加網(wǎng)絡(luò)流量。

面對(duì)這些方面的挑戰(zhàn)，分享一些關(guān)鍵技術(shù)，如 Service discovery、服務(wù)注冊(cè)、服務(wù)注冊(cè)模式、瓶頸/熱點(diǎn)、熔斷器和測試等。

Service discovery

對(duì)用戶而言，最難抉擇的是去哪個(gè)服務(wù)器上取數(shù)據(jù)，解決方案有客戶端發(fā)現(xiàn)和服務(wù)器端發(fā)現(xiàn)兩種。

如下圖，是客戶端發(fā)現(xiàn)：

客戶端發(fā)現(xiàn)，就是客戶端布設(shè) Service Instance，存放所有地址、各種信息?？蛻舳私邮盏綌?shù)據(jù)之后，可自行判斷去哪臺(tái)服務(wù)器上獲取信息。

如下圖，是服務(wù)端發(fā)現(xiàn)：

客戶端不需要寫很多程序，而是通過 Load Balancer 把信息轉(zhuǎn)到某個(gè)服務(wù)器。

服務(wù)注冊(cè)

服務(wù)注冊(cè)表是服務(wù)發(fā)現(xiàn)的關(guān)鍵部分，是一個(gè)包含服務(wù)實(shí)例的網(wǎng)絡(luò)位置的數(shù)據(jù)庫，需要高度可用且是最新的。

服務(wù)注冊(cè)一定不能宕機(jī)，一旦出現(xiàn)問題，恢復(fù)非常困難。服務(wù)注冊(cè)和發(fā)現(xiàn)部分，Netflix 采用的是自研 Eureka 組件。

服務(wù)注冊(cè)模式

服務(wù)注冊(cè)模式分為自注冊(cè)和第三方注冊(cè)兩種：

自注冊(cè)模式。這種方法的一個(gè)很好的例子是 NetflixOSS Eureka 客戶端。Eureka 客戶端處理服務(wù)實(shí)例注冊(cè)和注銷的所有方面。

Spring Cloud 項(xiàng)目實(shí)現(xiàn)了各種模式，包括服務(wù)發(fā)現(xiàn)，可以輕松地使用 Eureka 自動(dòng)注冊(cè)服務(wù)實(shí)例，只需使用 @EnableEurekaClient 注釋注釋您的 Java 配置類。

服務(wù)注冊(cè)模式相對(duì)簡單，并且不需要任何其他系統(tǒng)組件。但它將服務(wù)實(shí)例耦合到服務(wù)注冊(cè)表。您必須在您的服務(wù)使用的每種編程語言和框架中實(shí)現(xiàn)注冊(cè)碼。

如下圖，是第三方注冊(cè)模式：

開源注冊(cè)器項(xiàng)目—經(jīng) Registrator，會(huì)自動(dòng)注冊(cè)和注銷部署為 Docker 容器的服務(wù)實(shí)例，支持多個(gè)服務(wù)注冊(cè)表，包括 etcd 和 Consul。

NetflixOSS Prana 主要用于以非 JVM 語言編寫的服務(wù)，它是與服務(wù)實(shí)例并行運(yùn)行的邊路應(yīng)用程序。 Prana 使用 Netflix Eureka 注冊(cè)和注銷服務(wù)實(shí)例。

Registrator 的優(yōu)點(diǎn)是服務(wù)與服務(wù)注冊(cè)表斷開連接，不需要為開發(fā)人員使用的每種編程語言和框架實(shí)現(xiàn)服務(wù)注冊(cè)邏輯。

相反，在專用服務(wù)內(nèi)以集中方式處理服務(wù)實(shí)例注冊(cè)。缺點(diǎn)是除非它內(nèi)置在部署環(huán)境中，它是另一個(gè)高可用性的系統(tǒng)組件，需要設(shè)置和管理。

如何處理 FAN OUT

如下圖所示，單片服務(wù)里請(qǐng)求只有一個(gè)，而微服務(wù)里很多時(shí)候客戶端必須通過不同的微服務(wù)器才能把數(shù)據(jù)全部收集起來，請(qǐng)求繁多。

如下圖所示，解決的方法就是 Cache：

盡量把已經(jīng)擁有的數(shù)據(jù) Cache 起來，當(dāng)訪問時(shí)，優(yōu)先于 Cache，沒有再選擇其他部分。

瓶頸/問題

如下圖，當(dāng)遇到整個(gè)服務(wù)中某個(gè)變成瓶頸的情況，就會(huì)調(diào)用 X，X 要從用戶帳戶里拿數(shù)據(jù)。X 調(diào)用 Y，Y 也要從用戶帳戶里拿數(shù)據(jù)。

這樣一來，用戶服務(wù)會(huì)變成一個(gè)大大的瓶頸，一旦宕機(jī)，最前端的APP一定拿不到數(shù)據(jù)。

處理方法如下圖所示：

Netflix 用的比較多的方法是針對(duì)一些共用的數(shù)據(jù)不進(jìn)行反復(fù)調(diào)用，可采用 HTTP HEADER 傳遞數(shù)據(jù)。

如何提高可用性（Availability）？

微服務(wù)并不一定能保證可用性，甚至有時(shí)微服務(wù)做不好更容易宕機(jī)，所以一定要采用一些好的容錯(cuò)機(jī)制。

所謂容錯(cuò)，原則上說就是當(dāng)錯(cuò)誤發(fā)生，盡可能讓一臺(tái)服務(wù)器宕機(jī)。常見的解決方式有 Time out、Circuit peaker(熔斷器)和 Bulkheads (艙壁)-Reject new request 三種。

熔斷器在 Netflix 用的比較多，如下兩圖所示，為熔斷流程：

熔斷器主要應(yīng)用在當(dāng)一個(gè)服務(wù)去它的下游服務(wù)拿數(shù)據(jù)時(shí)，不應(yīng)該直接拿，要通過一個(gè)熔斷程序。

當(dāng)下游服務(wù)出現(xiàn)錯(cuò)誤，或延時(shí)很長時(shí)間，熔斷器就停止再到下游服務(wù)拿數(shù)據(jù)，直接返回。熔斷器也會(huì)不斷進(jìn)行判斷，服務(wù)是否恢復(fù)，恢復(fù)之后才會(huì)繼續(xù)拿取數(shù)據(jù)。

這樣一來，問題就會(huì)在某個(gè)地方被阻擋，不會(huì)出現(xiàn)服務(wù)接連問題，導(dǎo)致微服務(wù)出現(xiàn)大規(guī)模崩潰的現(xiàn)象。

微服務(wù)測試

測試是比較頭疼的環(huán)節(jié)，特別是微服務(wù)架構(gòu)端到端變得特別困難，主要原因是幾百個(gè)服務(wù)隸屬于不同的團(tuán)隊(duì)。

個(gè)人比較推薦單元測試（Unit Test）、服務(wù)測試（Service Test）。而端對(duì)端測試（End to End Test）要盡量避免，可以通過一些監(jiān)控工具來完成。

還有 Netflix 采用 ChaosMonkey 工具來對(duì)延遲和服務(wù)可靠性進(jìn)行測試。這里值得注意的是，每個(gè)微服務(wù)至少要有三個(gè)實(shí)時(shí)備份，以免宕機(jī)后無法恢復(fù)。

微服務(wù)帶來的企業(yè)組織結(jié)構(gòu)挑戰(zhàn)

之所以分享微服務(wù)帶來的企業(yè)組織結(jié)構(gòu)挑戰(zhàn)，是因?yàn)闅w根結(jié)底還是人在做事。微服務(wù)是去中心化，讓每個(gè)服務(wù)有獨(dú)立權(quán)，這樣會(huì)導(dǎo)致組織結(jié)構(gòu)發(fā)生很大的變化。

企業(yè)的組織構(gòu)架往往會(huì)反映在技術(shù)構(gòu)架中，微服務(wù)在企業(yè)內(nèi)部是否能夠成功，很大程度上取決于企業(yè)的組織構(gòu)架和技術(shù)構(gòu)架是否能夠匹配。

以 Netflix 為例，分享在向微服務(wù)構(gòu)架轉(zhuǎn)變的過程中對(duì)團(tuán)隊(duì)和企業(yè)構(gòu)架帶來的挑戰(zhàn)。

優(yōu)化速度，而不是效率

Netflix 在考量以速度還是以效率為優(yōu)化核心，最終選擇了速度。因?yàn)樗俣仁勤A得市場最重要的因素，速度意味著了解客戶需求，并以比競爭對(duì)手更快的速度給予他們想要的東西。在競爭對(duì)手準(zhǔn)備跟進(jìn)的時(shí)候，已經(jīng)轉(zhuǎn)到下一組改進(jìn)。

速度和效率是什么關(guān)系呢？強(qiáng)調(diào)效率通常意味著試圖控制開發(fā)過程的整體流程，以消除重復(fù)的工作并避免錯(cuò)誤的同時(shí)注意降低成本。

常見的結(jié)果是，注重節(jié)流，而不是開源。如果你說“我這樣做是因?yàn)樗行?rdquo;，那么這個(gè)意想不到的結(jié)果就是讓你慢下來。

這不是鼓勵(lì)浪費(fèi)和重復(fù)開發(fā)，但是應(yīng)該先優(yōu)化速度，效率成為次要。提高效率不是一個(gè)企業(yè)的終極目標(biāo)，提高效率要以業(yè)務(wù)增長更快為結(jié)果。

以結(jié)果為導(dǎo)向，減少不必要流程

盡量增加每個(gè)微服務(wù)團(tuán)隊(duì)的自由度，如開發(fā)工具，開發(fā)流程等方面，然后以結(jié)果為導(dǎo)向。

Netflix 有三個(gè)框架，其中 Java 占主流，每個(gè)團(tuán)隊(duì)可根據(jù)自身情況選擇技術(shù)構(gòu)架，甚至數(shù)據(jù)庫也可選擇 MySQL 或者 NoSQL。

盡量減少流程，為什么有流程呢？流程往往是對(duì)過去的事情的總結(jié)，如對(duì)一些錯(cuò)誤，經(jīng)驗(yàn)總結(jié)，之后用這個(gè)進(jìn)行流程控制。

但過多的流程會(huì)減慢對(duì)新生事物和突發(fā)情況的反映速度。還有要明確每個(gè)團(tuán)隊(duì)的目標(biāo)，減少互相依賴關(guān)系。

如下圖，是傳統(tǒng)公司的產(chǎn)品開發(fā)流程：

大多數(shù)軟件開發(fā)團(tuán)隊(duì)呈孤島狀，他們之間沒有人員重疊。軟件開發(fā)項(xiàng)目的標(biāo)準(zhǔn)過程從與用戶體驗(yàn)和開發(fā)組的產(chǎn)品經(jīng)理召開會(huì)議開始，一塊討論新功能的想法。

在代碼中實(shí)現(xiàn)該思想之后，代碼被傳遞給質(zhì)量保證（QA）和數(shù)據(jù)庫管理團(tuán)隊(duì)，經(jīng)常需要進(jìn)行很多溝通。與系統(tǒng)、網(wǎng)絡(luò)和SAN管理員的溝通往往是通過內(nèi)部的 TICKET 系統(tǒng)，導(dǎo)致整個(gè)過程非常緩慢。

有些公司試圖用初創(chuàng)公司的形式開發(fā)產(chǎn)品，但初創(chuàng)公司開發(fā)團(tuán)隊(duì)并不一定是微服務(wù)開發(fā)團(tuán)隊(duì)。公司雖會(huì)有很多個(gè)小的初創(chuàng)公司形式的小團(tuán)隊(duì)，但是每個(gè)團(tuán)隊(duì)內(nèi)部結(jié)構(gòu)還是和傳統(tǒng)公司的團(tuán)隊(duì)結(jié)構(gòu)一樣。

如下圖，是微服務(wù)產(chǎn)品研發(fā)團(tuán)隊(duì)：

微服務(wù)產(chǎn)品研發(fā)團(tuán)隊(duì)沒有不同的產(chǎn)品經(jīng)理、UX 經(jīng)理、開發(fā)經(jīng)理等，在其孤島中向下管理。

每個(gè)產(chǎn)品功能（實(shí)現(xiàn)為微服務(wù)）都有一名經(jīng)理，他負(fù)責(zé)監(jiān)督一個(gè)團(tuán)隊(duì)，從構(gòu)思到部署來處理各個(gè)方面微服務(wù)的軟件開發(fā)。

平臺(tái)團(tuán)隊(duì)提供產(chǎn)品團(tuán)隊(duì)通過 API 訪問的基礎(chǔ)架構(gòu)支持，在整個(gè)過程中，都采用 DeVop 形式發(fā)布和維護(hù)產(chǎn)品。

如何合理地選擇單片服務(wù)構(gòu)架和微服務(wù)構(gòu)架

并不是所有的場景都適合微服務(wù)，要根據(jù)實(shí)際情況，選擇微服務(wù)或單片服務(wù)：

    微服務(wù)適用于巨大流量、系統(tǒng)有一定復(fù)雜性、需要快速開發(fā)出新的產(chǎn)品、用戶數(shù)量增長迅速以及絕大多數(shù) TOC 的互聯(lián)網(wǎng)公司。

    單片服務(wù)的應(yīng)用場景一般是流量比較小、功能單一或非常簡單、不會(huì)快速迭代以及企業(yè)內(nèi)部工具，POC 工具或網(wǎng)站。

[[200918]]

前樂視美國視頻平臺(tái)技術(shù)總監(jiān)以及Netflix 視頻內(nèi)容平臺(tái)技術(shù)負(fù)責(zé)人。有 15 年以上互聯(lián)網(wǎng)公司（LinkedIn、樂視、Netflix 以及 PayPal）技術(shù)開發(fā)、構(gòu)架以及團(tuán)隊(duì)管理的經(jīng)驗(yàn)。主要負(fù)責(zé)的領(lǐng)域是高并發(fā)后端服務(wù)構(gòu)架、微服務(wù)構(gòu)架、大數(shù)據(jù)平臺(tái)構(gòu)架等，以及端對(duì)端的整個(gè)產(chǎn)品開發(fā)。感興趣的領(lǐng)域是視頻，支付，互聯(lián)網(wǎng)金融以及電商領(lǐng)域。

以上內(nèi)容根據(jù)羅軼民老師在 WOTA2017 “微服務(wù)架構(gòu)”專場的演講內(nèi)容整理。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】