上文我們主要介紹了DevOps與CI/CD，第三部分我們來講雲原生的核心概念-微服務。
什麼是微服務
微服務（Microservice）概念最早出現於2012年，2015年以後受到越來越多的關注，並且逐漸開始流行開來。其中著名技術大神Martin Fowler功不可沒，他於2014年發表的一篇博客《Microservices: a definition of this new architectural term》（微服務：新技術架構的定義）清晰的定義和闡述了微服務概念。
“要開始解釋什麼是微服務之前，先了解單體（Monolithic）應用是很有用的：作爲一整個單元構建的應用程序。企業應用由三個重要部分組成：客戶端界面（由HTML、Javascript組成，使用瀏覽器訪問）、數據庫、服務端程序。服務端程序處理HTTP請求、執行業務邏輯、檢索並更新數據庫中的數據、選擇和填充HTML視圖發送給客戶端。這個服務端程序是一個單一結構也即一個整體，系統中的任何修改都將導致服務端重新編譯和佈署一個新版本。
這樣一個單體應用很自然的被構建成爲一個系統，雖然可以使用開發語言的基本特性把應用封裝成類、函數、命名空間，但是業務中所有請求都要在單一的進程中處理完成，在某些場景中，你可以在開發人員的筆記本電腦中運行和測試，並且通過佈署通道將測試通過的程序佈署到生產環境中，你還可以水平擴展，利用負載均衡將實例佈署到多臺服務器中。
的確，單體應用也非常成功，但是越來越多的人感覺到了不妥，特別是應用程序被髮布到雲的時候，變更週期被捆綁在一起-對應用程序一小部分所做的變更，都需要重新編譯和部署整個應用。隨着時間的推移，軟件開發者很難保持一個好的模塊架構，使得單個模塊的變更不會影響到其它模塊，而且擴展時也只能進行整體擴展，而不能根據需求進行部分擴展。”-- Martin Fowler
下圖是傳統單體應用的技術及對應的組織架構，Martin Fowler稱之爲大家已熟知的Siloed Architectures-煙囪式（也稱爲穀倉）架構。
綜上，傳統的單體應用有很大的侷限性，應用程序隨着業務需求的迭代、功能的追加擴展，最終成爲一個龐然大物。單體應用的侷限性大體包括以下幾方面：
• 複雜性高：業務規模和團隊規模發展的一定階段，模塊耦合嚴重，代碼難以理解，質量變差
• 交付效率低：構建和部署耗時長，難以定位問題，開發效率低，全量部署耗時長、影響範圍廣、風險大，發佈頻次低
• 伸縮性差：單體只能按整體橫向擴展，無法分模塊垂直擴展
• 可靠性差：一個bug有可能引起整個應用的崩潰
• 阻礙技術創新：受技術棧限制，團隊成員使用同一框架和語言
解決這一問題的銀彈就是微服務。
“微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間相互協調、互相配合，爲用戶提供最終價值。每個服務運行在其獨立的進程中，服務和服務之間採用輕量級的通信機制相互溝通（通常是基於HTTP的Restful API)。這些服務要基於業務場景，並使用自動化佈署工具進行獨立的發佈。可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。”-- Martin Fowler
微服務架構將單體應用，按照業務領域拆分爲多個高內聚低耦合的小型服務，每個服務運行在獨立進程，由不同的團隊開發和維護，服務間採用輕量級通信機制，如HTTP RESTful API，獨立自動部署，可以採用不同的語言及存儲方式。微服務體現去中心化、天然分佈式，是中臺戰略落地到IT系統的具體實現方式的技術架構，用來解決企業業務快速發展與創新時面臨的系統彈性可擴展、敏捷迭代、技術驅動業務創新等難題。
下圖左邊是傳統的單體應用，右邊是微服務模式，圖中每種顏色代表一種可拆分的微服務應用。
一個比較形象的例子是裝配式建築。傳統建築（單體應用）的施工週期（開發時間）很長，往往依賴於建築公司（開發團隊）的能力和水平，修建完成後難以搬遷和複用，而裝配式建築（微服務）的梁、板、柱、牆等構件（單個服務）可以事先批量化的在工廠（容器）生產，而在建造過程中，我們可以把構件想象成一塊塊樂高積木，在施工現場只需把它們拼合在一起，大大提升了施工進度和建築質量。
微服務的特徵包括：
• 小：粒度小，專注於一件事
• 獨：單獨的進程。微服務不等於組件，服務是可以直接使用的商品，組件是待加工的原材料
• 輕：輕量級通信機制，通常是HTTP Restful的接口。此處區別於傳統的SOA（面向服務的架構）
• 松：松耦合，可以獨立部署。每個微服務可以獨立編譯、獨立部署、獨立運行
微服務架構的好處是：
• 易於開發與維護：微服務相對小，易於理解
• 獨立部署：一個微服務的修改不需要協調其它服務
• 伸縮性強：每個服務都可按硬件資源的需求進行獨立擴容
• 與組織結構相匹配：微服務架構可以更好將架構和組織相匹配，每個團隊獨立負責某些服務，獲得更高的生產力
• 技術異構性：使用最適合該服務的技術，降低嘗試新技術的成本
• 企業環境下的特殊要求：去中心化和集中管控/治理的平衡，分佈式數據庫和企業閉環數據模型的平衡
微服務的實踐有兩個重要問題：什麼時候選擇微服務架構，以及顆粒度如何拆分，與經驗和實際情況息息相關。
上圖來自Martin Fowler另一篇叫《微服務進階》的文章，揭示了生產率和複雜度的一個關係。在複雜度較小時採用單體應用的生產率更高，複雜度到了一定規模時，單體應用的生產率開始急劇下降，這時對其進行微服務化的拆分纔是合算的。
我個人建議是除非在可見的將來，複雜度都不會顯著提高的情況下，才選擇單體應用，否則其它時候都應提前爲微服務架構做好設計和準備。
微服務基礎設施及案例
下圖是一個典型的微服務技術架構圖。
微服務架構最常見、最廣泛使用的框架是基於Java的Spring Cloud（集成了上圖裏的Netflix OSS技術棧），提供了服務發現、負載均衡、故障轉移、動態擴展和數據分區等功能，已經成爲微服務的最佳實踐。
但是Spring Cloud構建在Java虛擬機之上，不能滿足高併發下的性能要求，所以許多開源產品層出不窮，其中也包括中國互聯網企業所貢獻的微服務框架，例如華爲的ServiceComb、阿里的Dubbo等等。
下面我們舉一個例子。傳統的電商的技術架構如下圖所示，這是一個單體應用。
所帶來的常見問題包括：
• 不同客戶端產品之間，例如小程序、App、網站端有許多相同業務邏輯的重複代碼，每個產品都要各自維護一份代碼，修改的時候所有地方要一起修改。
• 單個應用經常需要給其他應用提供接口，漸漸地越來越複雜，包含了很多本來不屬於它的邏輯，代碼變得臃腫，功能邊界模糊。
• 系統代碼耦合性高，相互之間邏輯複雜，一旦出現開發離職的情況，繼任者需要花很長時間review代碼，纔有可能搞清楚整體架構和邏輯關係。
• 多個應用使用一個數據庫，依賴性嚴重，很難重構和優化。所有應用都在一個數據庫上操作，數據庫很容易出現性能瓶頸。同時數據庫成爲單點，出現意外整個系統都會受到影響。
• 即使只改動一個小功能，也需要整個應用一起發佈，發佈流程繁瑣、上線時間長。並且很容易出現一個小bug影響整個系統，每次發佈都是膽戰心驚，很容易出現開發、運維和測試之間的矛盾。
下面我們用微服務重構整個系統：
改造之後，去除了大量冗餘代碼，系統複用性得到提升；不同的團隊專注於不同的微服務，代碼和工程質量得到保證；數據庫不再存在單點問題，系統健壯性得以提升；前後端分離，業務邏輯更加清晰；降低了系統耦合性，不同的微服務可以分開部署上線，相互之間並不影響。
組織挑戰、康威定律與蜂羣理論
請注意，微服務理念不僅反映了技術架構的變化，也反映了組織內部溝通結構爲了應對更加靈活、快速、碎片化的需求和環境而變化的結果。例如液態組織就是組織形態應對當前市場環境快速變化的一種輸出形式，但實際應該如何構建？
曾經有一張非常有名的組織架構圖，如下圖所示。
對一家企業來說，能一步步不斷髮展壯大，進入一個領域就能迅速突破，這其中的根本核心必然是組織模式。在粗放發展的年代，很少有企業強調內部效率，組織模式絕大部分都類似單體應用，按照職能劃分的方式進行管理，從而創造了無數的煙囪/穀倉。
我在我的知識星球裏提出過企業級產品設計所面臨的重要挑戰，其中一個問題是：
• 版本。企業級產品現在經常涉及多個平臺和不同的版本，例如Web、PC、App、釘釘、企業微信、微信小程序、飛書的版本等等，第一會面臨重複開發的問題，第二業務邏輯非常複雜，很容易造成產品邏輯和體驗的不統一，以及不同版本產品之間邏輯的缺失。例如登錄和註冊微信小程序可能用的是手機號，而通過郵件註冊需要使用的卻是郵箱。如何設計一套比較好的產品流程和組織架構，來保證統一完善的產品邏輯及用戶體驗？
是的，這不僅僅是產品和技術問題，還是組織問題。現在越來越多的企業意識到了最大的挑戰在於組織內部，無論是增長黑客還是MVP的理念都需要快速靈活的機制來配合。爲什麼有的組織效率高、能力強，能及時響應客戶的需求和環境變化？
新的組織設計理念認爲傳統的煙囪形式會成爲創建有效增長和盈利途徑的障礙，需要解構組織孤島，採用跨職能組織的形式以支持增長。企業組織設計是非常專業的領域，有許多文章討論，例如《戰勝組織孤島的戰略之路》，本文不延伸討論。
我們可以看到單體應用和職能組織，微服務與跨職能組織，在形式上是高度相似的，這引申出微服務背後的理論基礎。
“當希望把一個大型應用拆分成多個部分時，管理層通常將重點放在技術層面。而如果組織架構還按UI團隊、服務端邏輯團隊和數據庫團隊的標準設立，甚至一個非常簡單的變更都將導致跨團隊間的項目協作，從而耗費時間和預算審批。一個高效的團隊會針對這種情況進行優化，關注它們所涉及的應用邏輯，並從中做出更好的選擇。換句話說，邏輯無處不在。這是康威定律的一個實例。”-- Martin Fowler
設計系統的架構受制於產生這些設計的組織的溝通結構（Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations）-- Melvyn Conway, 1967
康威定律可謂軟件架構設計中的第一定律，本質是對商業世界的規律總結，但是因爲投稿到編程相關的雜誌，後經過《人月神話》這本軟件界聖經的引用，並命名爲康威定律（Conway's law），因此得以推廣。
只通過簡單的描述可能無法理解康威定律的精髓所在，原文中康威定律可總結爲四項：
• 第一定律 組織溝通方式會通過系統設計表達出來（Communication dictates design）
• 第二定律 時間再多一件事情也不可能做的完美，但總有時間做完一件事情（There is never enough time to do something right, but there is always enough time to do it over）
• 第三定律 線型系統和線型組織架構間有潛在的異質同態特性（There is a homomorphism from the linear graph of a system to the linear graph of its design organization）
• 第四定律 大的系統組織總是比小系統更傾向於分解（The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems）
例如微服務的團隊間應該是inter-operate，not integrate（互操作、不集成）。inter-operate是定義好系統的邊界和接口，在一個團隊內全棧，讓團隊自治，原因就是因爲如果團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每個子系統就會更加內聚，彼此的依賴耦合變弱，跨系統的溝通成本也就能減低。
康威定律可以上升到哲學的高度進行討論，但是過於複雜。簡言之，微服務架構與組織模式互相決定和影響，協同才能發揮出最大價值。
凱文·凱利在《失控》中提出了著名的“蜂羣理論”，利用蜂巢思維比喻人類的協作帶來的羣體智慧：依靠成千上萬個發條一起驅動一個並行的系統，進行生產，進行自維持。蜂巢思維就是“羣體思維”（Collective consciousness）。作爲“超級有機體”的蜂羣，被稱爲“分佈式系統”，是以生物邏輯建立起來的羣集模型。由此形成的蜂巢思維這四個理念至關重要：
1）去中心化。幾乎所有的團隊都直接接觸用戶與市場，因此所有的團隊都將圍繞市場格局而變，充分重視第一線的敏感度與直覺，從而做到真正的應時而動；
2）分佈式。與垂直型集團組織不同，這個形態打破單一的行業垂直細分格局。在這種多維度矩陣式結構中，擁有更加專注的功能型團隊，可建立起一個緊密圍繞具體客戶與市場的服務體系；
3）強化合作。從控制權、所有權的角度來說，這些組織單元是分離的，因而要建立起一種橫向合作的文化，打破物理團隊，提倡交流、合作，整體核心競爭力的提升；
4）適應變化。市場在不斷變化，但因所有的團隊都直接接觸用戶與市場，因此無論個人還是團隊，都將不斷的學習和進化。
微服務理念對應的組織模式包括蜂巢型組織，它具有突出的穩定性和抗彎曲能力，特點是：
• 跨組織：它不一定是一個獨立的法人實體，而是爲了特定目標或項目形成的聯盟
• 相對統一：蜂巢組織不是一成不變的，當市場需求或組織目標發生變化時立即變化
• 分享性：它改變了傳統的等級分明的金字塔結構，允許信息橫向傳遞與交流，使信息利用更爲充分及時
在這樣一個以蜂巢爲理念搭建的企業圈層裏面，各個獨立團隊能夠得到更好的協助與支撐，不斷擴大視野，提高眼界，掌握話語權，團隊成員也會更有歸屬感。這樣的團隊乃至蜂巢本身，也一定會更有活力和變革力，更加能適應市場的變化。蜂巢型組織有四個突出特點，所謂活系統的特質也正是由此而來：沒有強制性的中心控制；次級單位具有自治的特質；次級單位之間彼此高度連接；點對點間的影響通過網絡形成了非線性因果關係。
蜂巢型組織的典型案例之一是華爲。除了組織架構去中心化的管理模式之外，華爲的著名的輪值CEO制度正是由此而來，華爲有三位輪值CEO，每六個月輪換一次，這體現了依靠集體民主決策而非一人獨裁的理念。
再例如國美蜂巢式組織變革的實踐是將由四個大區管轄54個分公司，調整爲七個大區直接管轄200家分公司的結構，即將原來二級市場裏的146家分公司獨立出來，直接劃歸大區管轄，而原來四個大區變成七個大區。實踐證明，組織扁平化是國美提升供應鏈效率，提升消費者消費體驗的重要戰略。
國外著名的代表案例是微服務先驅Netflix。Netflix是一家技術強大的互聯網公司，但是它卻沒有CTO職位，產品團隊和技術團隊(包括UI前端工程團隊、Discovery搜索工程團隊和Platform平臺團隊等)全部彙報首席產品CPO，產品驅動是該公司的核心文化要素之一，Netflix稱其爲BusDevOps組織架構。
在整個系列第二部分中，我們介紹了DevOps，現在我們可以理解，DevOps是配合微服務的理念組織構建團隊協作的方式，各團隊可以獨立開發，測試、發佈和迭代各自的微服務，互不干擾，溝通協調成本小。全部業務、研發和運維圍繞產品開展工作，統一目標，大家都是產品驅動，分別服務於內外不同客戶，避免技術驅動 vs 業務驅動的陷阱。
在某些文章中，認爲微服務的切割應該按照組織架構來劃分，我反而覺得應該按微服務的分割方式來劃分組織架構，因爲歸根結底，組織架構應該爲業務服務，而不是業務爲組織服務，組織需要貫徹執行微服務的理念，就必須由微服務驅動組織業務的不斷迭代演進。
微服務與中臺
可能有人會問，中臺的目標不也是爲了解決企業內部業務系統煙囪林立，數據孤島嚴重，各自爲戰，缺乏複用性，所以要充分提取業務共性，從而及時應對需求變化，聽起來和微服務的目標和理念非常相似，那它們之間有什麼異同呢？
來自阿里官方的定義，“企業中臺就是，將企業的核心能力隨着業務不斷髮展以數字化形式沉澱到平臺，形成以服務爲中心，由業務中臺和數據中臺構建起數據閉環運轉的運營體系，供企業更高效的進行業務探索和創新，實現以數字化資產的形態構建企業核心差異化競爭力。”
中臺架構，簡單地說，就是企業級能力的複用，一種方法論，企業治理思想。
微服務，是可獨立開發、維護、部署的小型業務單元，是一種技術架構方式。
所以中臺並不是微服務，中臺是一種企業治理思想和方法論，偏向於宏觀，微服務是技術架構方式，偏向於微觀。而中臺化的落地，離不開使用微服務架構。
中臺強調核心基礎能力的建設，基礎能力以原子服務的形式來建設，並通過將原子服務產品化，支撐業務端各種場景的快速迭代和創新；原子服務和微服務所倡導的服務自閉環思想不謀而合，使得微服務成爲實現原子服務的合適架構。
支撐業務場景的應用也是通過服務來實現，其生命週期隨業務變化需要非常靈活的調整，這也和微服務強調的快速迭代高度一致，所以業務應用服務也適合通過微服務來實現。
API管理與API集成
下面我們講講微服務相關的兩個具體領域，API管理與API集成。
1、全生命週期API管理
上文提到微服務各個服務對外都是以Restful API形式提供服務。再加上企業越來越多地使用雲服務，各種雲服務也提供了衆多API。
這就導致企業擁有的API越來越多，那就當然需要有一個系統把這些API統一管理起來。同時，如果能夠順便把這些API的權限認證、安全審計等等機制也一併統一了，那就更好了，這樣其它系統調用起來就方便多了。能管了以後，當然又會冒出來更多的想法。比如，能不能改一下原有API的格式內容？能不能把兩個API合成一個API？能不能讓一個API直接調用另一個API？能不能把這些API的調用自動化串起來？
簡單來說，API管理就是解決以上這些問題的。我們來看看Gartner全生命週期API管理領域魔力象限，許多巨頭都在裏面。值得注意的是，Google之所以排名第一，是因爲它在2016年用6.5億美元收購了剛上市一年左右的Apigee。
2、API網關：微服務基礎設施
全生命週期API管理裏一個細分的領域是API網關（API Gateway），它是微服務1.0時代最重要的基礎設施。
API網關顧名思義，是出現在系統邊界上的一個面向API的、串行集中式的強管控服務，這裏的邊界是企業IT系統的邊界，主要起到隔離外部訪問與內部系統的作用，並處理常見的南北向流量。在微服務概念的流行之前，API網關的實體就已經誕生了，例如銀行、證券等領域常見的前置機系統，它也是解決訪問認證、報文轉換、訪問統計等問題的。
API網關的流行，源於近幾年來，移動應用與企業間互聯需求的興起。移動應用、企業互聯，使得後臺服務支持的對象，從以前單一的Web應用，擴展到多種使用場景，且每種使用場景對後臺服務的要求都不盡相同。這不僅增加了後臺服務的響應量，還增加了後臺服務的複雜性。隨着微服務架構概念的提出，API網關成爲了微服務架構的標配組件。
API網關作爲企業能力開放的一個門戶，除了具備基本的請求轉發、協議轉換、路由等功能，以及高性能和高穩定性外，還需具備良好的擴展性，已便於網關能力的不斷增強。在網關實施過程中，要規劃好網關層與服務層的交互方式，儘量使得網關層與服務層解耦，便於各個團隊工作的獨立性。另外，在API的管理上，需要提供API全生命週期的發佈、配置、鑑權、流控、監控等配套的管理功能。
例如Uber，在傳統的單體架構遇到越來越大挑戰的時候，決定改變自己的架構，效仿亞馬遜、Netflix、Twitter等其他超級增長公司，將其整體架構拆分爲多個代碼庫，以形成一個微服務架構。其主要變化是引入了API網關，所有的司機和乘客都是通過這個網關連接的。從API網關，所有的內部點都連接在一起，如乘客管理、司機管理、行程管理等。每個單元是單獨的可部署單元，執行單獨的功能。例如：如果你想在賬單微服務中更改任何內容，那麼只需部署賬單微服務，而不必部署其他服務。所有的功能都是單獨擴展的，即每個特徵之間的相互依賴被移除。
API網關帶來的的好處包括：
• 網關層對外部和內部進行了隔離，保障了後臺服務的安全性
• 對外訪問控制由網絡層面轉換成了運維層面，減少變更的流程和錯誤成本
• 減少客戶端與服務的耦合，服務可以獨立發展。通過網關層來做映射
• 通過網關層聚合，減少外部訪問的頻次，提升訪問效率
• 節約後端服務開發成本，減少上線風險
• 爲服務熔斷，灰度發佈，線上測試提供簡單方案。
• 便於擴展
API網關常見的解決方案包括Spring Cloud Gateway、Zuul、Tyk以及下文要介紹的Kong。
3、Kong：API網關獨角獸
Kong是我去年起就在關注的一家公司，它的創業歷程非常有意思。“Kong的創始人Augusto Marietti（簡稱Aghi）出生在羅馬，因爲意大利創業環境很弱，在2009年飛來了舊金山。Aghi剛來就參加了一個早期創業者的小聚會，聚會上參加的人不多，但現在都是如雷貫耳的名字：Uber的創始人Travis，Airbnb的CEO Brian，Dropbox的CEO Drew和Box的CEO Aaron。Aghi當時爲了省錢，借住在Uber創始人Travis家，每天睡沙發。
後來Travis搬了家，Aghi又去了當時只有十多個人的Airbnb辦公室裏借住，當時的Airbnb雖然Bug很多，但訂單量一天天瘋漲。在Travis的幫助下拿到天使投資後，Aghi做了一個把雲端的組件連接起來的PaaS公司，一做就是五六年。由於時機不對，公司瀕臨破產，Aghi告訴團隊，這麼多年公司寫了很多小功能，現在可以把代碼開放出去，放在網上看看有沒有人用，給社區做點貢獻。沒想到這看似瀕死的掙扎，卻給公司帶來了巨大的轉機。
後來，公司關於API管理的代碼模塊，在GitHub上被瘋狂下載，Kong也接到客戶要求，希望購買相應的付費企業版。Kong敏銳地發現了這個大機會，迅速轉型成了一個開源軟件公司。”如果在CSDN博客上搜索，關於Kong開源版本的教程比比皆是。這是一個成功的開源軟件商業化的案例，聽起來經歷和Docker非常相似。
Kong成長的大背景是軟件開發技術正在經歷革命性變化，全球5000強公司都在轉向新的分佈式軟件架構，因爲現代應用程序需要有高度可擴展性、跨平臺支持以及處理實時數據流的能力。IDC預計，到2022年90%的應用程序將採用微服務架構和第三方代碼，35%的生產應用程序將誕生於雲端。由於容器和敏捷方法的採用，預計2018-2023年間將誕生5億個新應用程序。
同時開源軟件初期具有的優勢也在逐漸顯現。Kong本身基於開源的Openresty（Nginx+lua），但比Nginx提供了更簡單的配置方式，數據採用了Apache Cassandra/PostgreSQL存儲，由於底層使用Nginx，所以性能比基於Java的Spring Cloud Gateway及Zuul更爲出色。Kong另外一個非常誘人的地方就是提供了大量的插件來擴展應用，通過設置不同的插件可以爲服務提供各種增強的功能。Kong默認插件包括：身份認證、安全、流量控制、分析監控、轉換等等。
Kong提供開源的Kong Gateway和商業版Kong Enterprise兩個產品。例如在插件功能上，商業版本提供更多的選擇。
Kong通過雲原生、混合和本地部署無縫連接API和微服務，便於程序員開發可擴展的微服務應用，推動業務增長。憑藉高性能的開源內核和AI技術以及機器學習，Kong將實現全方位的服務生命週期管理，覆蓋前期到後期全過程，幫助客戶搭建和管理創新產品及服務。它服務於全球5000強企業，幫助程序員更方便地開發和管理高性能、可擴展的微服務應用，推動業務增長。
從業務和融資上來講，2018年，Kong訂單大幅增加，公司員工數翻倍，已服務超過100家企業客戶，包括雅虎日本、法拉利、SoulCycle、WeWork等，開源軟件下載量超過5400萬次，收入爲500萬美元。2019年，Kong完成了Index Ventures領投，GGV紀源資本、World InnovationLab跟投，老股東Andreessen Horowitz、Charles Rivers Ventures追加的4300萬美元C輪融資，至此Kong累計融資共計7100萬美元。
4、RapidAPI：全球最大API市場
和Kong緊密相關的另外一家企業是RapidAPI，2017年，Kong的母公司Mashape將其API市場業務與RapidAPI合併，從而組成了世界上最大的API市場。
市場研究機構Ovum Research曾經表示，API經濟在迅迅猛發展，到2018年將成爲產值高達2.2萬億美元的市場。合併後，RapidAPI成爲了這個市場的主要提供商之一。
RapidAPI的首席執行官吉納在宣佈合併的博文中表示，“軟件相互連接起來後，其功效就要大得多。不妨想一想。你使用Facebook登錄到某個遊戲應用程序，就能看到玩遊戲的所有朋友。當亞馬遜的購買門戶網站與倉庫存貨連接起來後，你就能實時獲得發貨估計日期。如果你在訂購機票呢？已經在你的谷歌日曆中預定了航班。”吉諾補充道，API正是讓那些連接成爲可能的祕訣。“它們讓不同的軟件得以彼此聯繫，共享信息，並且簡化我們的生活。”
吉納在博文中表示這只是開了個頭。API正在迅速發展，打開之前緊閉的許多大門。使用API，開發人員就有可能從任何地方來訪問服務，比如IBM公司的超級計算機和谷歌的機器學習模型，這就意味着他們能夠充分利用比以前處理的任何資源豐富得多的資源。
吉納說：“我們想要讓廣大開發人員更容易尋找、測試和連接API。我們的計劃始終未變，那就是將世界上的所有API統統集中到一個地方。將Mashape API市場合併到RapidAPI讓我們離實現這個目標比以往更近了一步。現在我們每月總共有370000名開發人員在調用3000億次API。也就是說，每秒的API調用超過100000次。”
RapidAPI的市場裏包括各種各樣類型的API，例如天氣、體育、科技、通訊、圖像處理等等，例如獲取新聞信息、實時體育比賽比分、天氣信息，甚至還包括新冠病毒API分類。
開發商可以自由的爲自己的API接口定價，下圖是Twilio SMS接口的報價方案。
2019年，RapidAPI完成了由微軟領投、A16Z等跟投的2500萬美元B輪融資，歷史累計融資達到3750萬美元。RapidAPI表示，它將利用這筆新籌集的資金擴大其API市場規模，並推動其新發布的RapidAPI for Teams產品。它是一個自助服務平臺，使開發人員能夠發佈，管理和協調API和微服務，這些是用於構建現代應用程序的常用組件。
5、Mulesoft：API集成/iPaaS/API管理領頭羊
1）從SOA講起
講API管理之前，我們得先來說說前文提到過的SOA（Service-Oriented Architecture，面向服務的架構）。
簡單地說，一個企業建設了許多業務系統，每個系統都擁有自己的數據，那麼如何將這些分散各處的數據打通，從而可以進一步加以利用呢？
這就涉及到企業應用集成（EAI，Enterprise Application Integration）這個領域了。
傳統上，企業應用集成很多是利用ETL（Extract-Transform-Load，抽取轉換加載）工具，把不同系統裏的數據經過抽取、過濾、轉換，最終導入到一個集中的數據倉庫裏，然後再做整合應用。但是這種做法也存在很多問題。
一是隻認數據，沒有腦子。在數據彙集的過程中，只能針對數據格式本身進行一些處理，很難利用業務系統原有的業務邏輯。
二是隨着各個系統數據體量越來越大，把所有系統的數據都匯到一個數據倉庫裏就變得越來越困難。
爲了解決這樣的問題，SOA應運而生，就是企業中每個系統都對外發布自己的服務，那麼系統之間的集成，就可以通過調用對應系統的服務來解決了。
但是，隨着企業擁有的系統越來越多，這種系統之間相互調用服務接口的集成方式又遇到了新麻煩。
可能每兩個系統之間都需要相互調用服務，這最終就會演變成一個複雜的蜘蛛網結構，使得整個集成變得越來越脆弱，難以維護。
爲了解決這個新問題，ESB（Enterprise Service Bus，企業服務總線）的概念被提出來了，就是把每個系統的服務接口都對接到ESB上，這樣在系統集成的時候，只需要跟總線打交道，而不再需要直接跟所有其它系統打交道了，從而大大簡化了集成的複雜度。
2）Mulesoft
2018年3月，美國SaaS巨頭Salesforce花費65億美元收購iPaaS代表企業Mulesoft，Mulesoft於2017年在紐交所上市，市值約30億美元。Mulesoft的核心產品是企業軟件集成平臺Anypoint Platform（舊稱Mule ESB），客戶可以在Anypoint上集成所有業務系統的服務，實現本地系統與雲、以及雲與雲服務的集成。Anypoint Platform/Mule ESB是世界上使用最廣泛的開源ESB產品，已擁有超過數百萬的下載量，以及來自世界各地數十萬個開發人員，財富500強中35%的企業、全球10大銀行中的5家均使用了該平臺。
儘管只有一個產品，但從Gartner的劃分標準來看，Mulesoft同時踩在了兩個領域裏：全生命週期API管理和企業集成平臺即服務（iPaaS，Enterprise Integration Platform as a Service）。
Mule ESB同時包括開源和商業版本，在各個技術論壇上遍佈其技術教程。
Mulesoft的成長曆程非常具有參考意義，他們瞄準了一個有7000億美元空間的市場，目標是解決一個十分困難的IT問題-集成。在摸索過程中Mulesoft不斷優化其產品形態和銷售方式，例如針對大客戶需要的不僅是平臺提供的通用功能，還需要更復雜的綜合服務。於是MuleSoft把他們的銷售方式從出售可靠的集成功能，變成了向高級管理人員出售提升企業連接能力的願景和相應的解決方案，客單價也從10-30000美元提升到了500萬美元。
3）應用場景與案例
Mule ESB的常見應用場景例如：
• 舊系統改造，開放系統的服務能力。舉個例子，企業有一個電商系統，需要調用SAP ERP的訂單接口來創建訂單，這個時候需要將SAP的訂單服務暴露成流行的Restful API，以方便電商系統調用。使用Mule ESB可以輕鬆實現。
• 系統集成。企業之間的數據交換，竟然有一半以上是文件的形態進行的，這在互聯網思維普及的今天，是不容易想象的。在10年前，企業間交換數據採用文件形態的比重佔60%，當時普遍認爲這個比重會迅速下降，最終以接口服務形態進行交換的比重會佔絕大多數。然而10年後直至今天，採用文件形態的依然佔51%的比重。其實仔細想想，也不無合理。兩個對等企業之間，行業上下游多個企業之間，不同系統之間的進行數據交換，採用文件的形式，可能是最簡單便捷的方式。舉個例子，很多系統之間數據交互可能還是用FTP目錄。尤其是企業跟企業之間的數據交互，比如，A企業丟一個EDI文件到B企業的FTP目錄，然後B企業會從FTP目錄下載解析並放置到數據庫。這個場景用Mule ESB實現也很方便。
4）Salesforce爲什麼收購Mulesoft
Salesforce最初爲中小企業提供SaaS的CRM，而隨着大客戶越來越多，定製化、個性化的需求也越來強烈，所以就需要提供PaaS平臺解決個性化、定製化的問題。
而這個定製化，最開始只是以Salesforce爲核心的功能延伸及簡單擴展，而隨着個性化需求的不斷深入，這種定製已經逐步演變爲更大規模的多個骨幹數據源之間的數據集成與交換，Salesforce可能只是多個數據源之一。
所以也可以說，數據集成是PaaS平臺的上層建築，Salesforce需要幫助客戶解決整合不同數據源所帶來的挑戰。
收購之後，Salesforce會將MuleSoft植入進Salesforce Integration Cloud，從而幫助客戶連接多個數據源，並計劃在之後推出集成雲。
所以，可以看出Salesforce其實更在乎的是集成（Integration）這個詞。
5）iPaaS、API管理與API集成
iPaaS的集成不光是針對雲服務，也包括本地系統，這樣就解決了混合雲模式下的集成問題。iPaaS集成的範疇，除了API接口之外，一般還會包括更多種類的協議（比如FTP、數據庫），也包括對於文件數據的集成。
從這個角度來理解，API管理更關注API的治理與整合，iPaaS關注更大範疇的集成，包含API集成的概念。
6）SOA、ESB與微服務的關係
微服務架構和SOA架構非常類似，微服務是SOA的昇華，只不過微服務架構強調的是“業務需要徹底的組件化及服務化”，原單個業務系統會被拆分爲多個可以獨立開發、設計、部署運行的小應用，這些小應用間通過服務化完成交互和集成。
ESB是一種集中式服務治理的架構，看上去微服務中不需要ESB，Martin Fowler也不贊同在微服務架構中繼續用ESB。
我們下面要介紹到的下一代微服務架構核心-服務網格，則可以視爲分佈式的ESB。
微服務2.0：服務網格與Serverless
1、服務網格
微服務當前遇到的挑戰包括：
• 技術門檻高：開發團隊在實施微服務的過程中，除了基礎的服務發現、配置中心和鑑權管理之外，團隊在服務治理層面面臨了諸多的挑戰，包括負載均衡、熔斷降級、灰度發佈、故障切換、分佈式跟蹤等，這對開發團隊提出了非常高的技術要求。
• 代碼侵入性強：Spring Cloud、Dubbo等主流的微服務框架都對業務代碼有一定的侵入性，技術升級替換成本高，導致開發團隊配合意願低，微服務落地困難。
爲了解決上述問題，號稱微服務2.0的服務網格（Service Mesh）應運而生。服務網格這個詞最早由著名開源服務網格項目Linkerd所在的Buoyant公司CEO William Morgan所提出。按照他的定義，服務網格是一個軟件基礎設施層，用於控制和監視微服務應用程序中的內部、服務到服務的流量。
Sidecar是服務網格中的核心組成部分，可以看到，上圖中每一個微服務都配備了一個Sidecar。此時用戶只需要關心業務邏輯，而不用關心服務治理等非業務功能，非業務功能都由Sidecar負責，接管對應服務的入流量和出流量，並將微服務架構中的服務訂閱、服務發現、熔斷、限流等功能從服務中抽離到Sidecar中。
服務網格和API網關是兩個聯繫非常緊密的概念，它們的用途既不同，但是在某些方面又相互重疊。在某種程度上，我們可以認爲服務網格是一個分佈式的、微觀層面的API網關，解決微服務服務發現、負債均衡、流量控制等需求。在具體用途上，API網關處理的是所謂南北向流量即內外部請求；而服務網格處理的是東西向流量即內部服務相互間的訪問。想深入瞭解兩者區別的讀者可以詳細閱讀《Service Mesh和API Gateway關係深度探討》這篇文章。
服務網格相關的著名項目包括Linkerd、Envoy和最受歡迎的服務網格框架Istio。Kong也於2019年發佈了基於Envoy的開源服務網格產品Kuma。
下圖是CNCF Landscape裏服務網格分類所羅列的項目，其中Linkerd正由CNCF進行孵化。
2、Serverless
Serverless（無服務器架構）這個概念在2012年時便已經存在，比微服務和服務網格的概念出現都要早，但是直到微服務概念大紅大紫之後，Serverless才重新又被人們所關注。
Serverless是一種構建和管理基於微服務架構的完整流程，它與傳統架構的不同之處在於，完全由第三方管理，由事件觸發，存在於無狀態、暫存的計算容器內。Serverless相關的重要概念包括FaaS（Functions as a Service，函數即服務）。開發者把函數上傳到雲廠商的FaaS平臺，函數只在被請求時才實例化運行，然後被銷燬，其它時候不佔用任何服務器資源，完全實現按需使用，大幅度降低了服務器佔用和成本。
Serverless通常適用於實時性要求不高、無狀態的場景，例如突發事件處理、數據統計分析、視頻解碼、離線批量計算等等，像AWS FaaS平臺Lambda限制用戶功能必須在15分鐘內完成。
相較服務網格，Serverless概念更爲超前，雖然AWS Lambda、阿里雲等許多平臺都已經提供對其的支持，但是目前仍處於發展早期，無論是成熟項目數量和企業應用程度都相對有限。
微服務 vs 宏服務：新的抉擇
最近，Uber支付體驗平臺的工程經理Gergely Orosz發佈推文表示他們的架構方向已經發生了變化。
“聲明一下，在Uber，我們正將許多微服務轉移到@copyconstruct所稱的Macroservices宏服務（大小適中的服務）。
確切地說，B/C測試和維護成千上萬的微服務不僅很難——它可能會帶來更多的長期麻煩，而不是解決短期問題。
微服務確實可以幫助團隊在早期快速推進。
等你意識到服務越少越好時，已爲時已晚。你需要解決很多服務的“困難”部分。
我們在不斷增加更多的服務，但也在停止使用服務，並且會更慎重的思考新的服務。“
全部的上下文可以在這裏閱讀。有一篇英文文獻中這樣描述Macroservices宏服務：宏服務應該定義爲運行2-20個單獨服務的應用程序體系結構，每個服務代表一箇中等大小的代碼庫，可處理業務中定義明確的部分。宏服務的關鍵是拆分服務，最大程度地從拆分中獲得收益，同時最大程度地降低運行多個服務的開銷。通俗點講，宏服務介於單體服務到微服務之間，關注的不再是某一個細節點，而是一個業務點。
實際上，宏服務目前的定義並不清晰，影響和實踐相當有限，也並非比微服務更優的解決方案，本質還是不同企業和團隊在架構演進中對於系統複雜性的不同度量。
總結
微服務的理念不同的團隊有不同的實踐，例如微服務如何拆分、組織架構如何搭建、技術棧如何選擇。
我們理解，微服務是雲原生的核心，後面要介紹到的容器（Docker）和Kubernetes是實現的技術方法和手段，DevOps是配合的文化和研發流程，但是微服務帶來的啓發，更多是思維方式上的轉變。
從下一部分開始，我們將分兩期介紹兩大核心技術：Docker和Kubernetes。
下一期內容爲《雲原生時代（四）：容器與Docker》
參考文檔：
本文的部分內容參考或者引用以下文章，在此表示感謝，如果有涉及知識產權的問題，請聯繫我及時修改。
Service Mesh 和 API Gateway 關係深度探討
A text interpretation of the cloud native (rpm)
走訪了十幾家美國企業服務公司，我們寫下了這篇萬字文章 | GGV投資筆記第一期
Mashape 和 RapidAPI 合併，組成全球最大的應用編程接口（API）集市！
Service Mesh 和 API Gateway 關係深度探討