本文是 Choerodon 豬齒魚微服務系列文章的第一篇，在文章中將介紹當前比較流行的兩種微服務架構，即 Dubbo 和 Spring Cloud，同時將總結 Choerodon豬齒魚在選擇使用微服務架構中的一些實踐經驗，希望能夠給大家一些借鑑和啟迪。
▌文章的主要內容包括：
- 什麼是微服務架構
- Dubbo 的誕生背景
- Spring Cloud 應運而生
- Kubernetes + Docker使微服務實施成為一種可能
- 微服務“新秀”——Service Mesh
在Choerodon豬齒魚設想之初，我們希望基於容器技術，整合DevOps工具鏈、微服務應用框架，開發一個企業級的PaaS平臺，來幫助企業實現敏捷化的應用交付和自動化的運營管理。同時，也確定了技術堆疊的要求，即充分地使用主流成熟的開源元件，利用開源工具的擴充套件機制來構建平臺，打造一個開放的技術平臺和體系，讓企業享受到開源社群的成果。
當然，羅馬不是一天建造起來的。從初期確定技術棧到現在，除Choerodon豬齒魚平臺具體應用的實踐與迭代，平臺的技術棧也在不斷進行著迭代。在開源社群中解決一個相同問題的開源技術有很多，而如何驗證甄別哪些開源技術既能夠滿足現在的系統需求，在未來又有比較好的適應性，就給廣大的架構師和軟體設計師提出了挑戰。根據Choerodon豬齒魚實踐經驗，在使用開源技術時，可以從如下幾個方面來進行考慮：
- 語言 - 選擇開源技術一個非常核心的考量是儘量使用應用比較廣泛的開發技術，避免涉及相對來說的新技術、開發語言，這樣可以進一步研發降低成本。例如Java的使用非常廣泛。
- 成熟度 - 開源技術的版本是否已經發布穩定版本或者更高版本是其成熟的重要標誌，例如Istio在8月釋出1.0版本，促使了很過公司和產品跟進使用；如果產品仍處於孕育階段，則其技術變更的風險就比較大，例如 Apache 的 incubating 、 0.XXX版本或者beta版本等都有可能有各種技術缺陷或者沒有經過較好的實際檢驗。
- 社群 - 開源社群的活躍度在一定程度上反映了整個技術的生命力，例如是否有大量相關社群存在，K8s在國內就有Kubernetes中文社群，K8s中文社群等，以及定期還有各種關於K8s的Meetup或者論壇等；當然GitHub 上的 stars 的數量是一個參考指標，以及貢獻者數量、程式碼更新頻率等。
- 生態圈 - 圍繞開源技術是否有活躍健康的生態圈，是否有比較多的使用者在使用，尤其是一些大公司，以及圍繞開源產品是否有較多的文章、知識分享，或者圍繞產品的某一塊功能第三方增強開源工具，例如圍繞Hadoop有Sqoop、Hbase、Hive等。
- 文件 - 完備並及時更新的文件，非常有利於使用者瞭解開源產品的設計思路、安裝、使用等，方便產品在使用者這邊落地實踐。想想 sourceforge.net 上如今已是程式碼的墳墓，沒有文件的程式碼生命週期通常都不長。
- 資源 - 開源技術如果在業界比較高的人氣，應該有比較多的使用者，市場上相關人員資源也非常豐富，比較有利於團隊技術人員的補充。
到目前為止，Choerodon豬齒魚經過不斷地迭代，逐漸形成了以 Spring Cloud + Kubernetes 為主體的微服務技術體系。
什麼是微服務架構
在開始介紹之前，首先需要了解什麼是微服務架構？ 2014年初（該年可以稱之為微服務的元年），微服務之父 Martin Fowler 在其部落格上發表了"Microservices" 一文，文中正式提出了微服務架構風格，並指出了微服務架構的一些特點。
簡單地說，微服務是系統架構上的一種設計風格，它的主旨是將一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的程式中執行，服務之間通過基於HTTP的RESTful API進行通訊協作。被拆分的每一個小型服務都圍繞著系統中的某一項或一些耦合度較高的業務功能進行構建，並且每個服務都維護著自身的資料儲存、業務開發、自動化測試案例以及獨立部署機制。由於有了輕量級的通訊協作基礎，所以這些微服務可以使用不同的語言來編寫。-- 作者 James Lewis and Martin Fowler， 翻譯自《Spring Cloud微服務實戰》
在傳統的單體應用系統架構中，一般分為三個部分，即資料庫、服務應用端和前端展現，在業務發展初期，由於所有的業務邏輯在一個應用中，開發、測試、部署都比較容易。但是，隨著業務的發展，系統為了應對不同的業務需求會不斷為單體應用增加不同的業務模組。久而久之，不斷擴充的業務需求導致單體應用的系統越來越龐大臃腫。此時，單體應用的問題也逐漸顯現出來，由於單體應用是一個“整體”，往往修改一個小的功能，為了部署上線就會影響到其他功能的執行。而且，對於業務而言，往往不同模組對系統資源的要求不也盡相同，而單體應用各個功能模組因為無法分割，也就無法細化對系統資源的需求。所以，單體應用在初期是比較方便快捷，但是隨著業務的發展，維護成本會越來越大，且難以控制。
Martin Fowler 認為微服務架構與單體應用最大的區別在於，微服務架構將一個完整的單體應用拆分成多個有著獨立部署能力的業務服務，每個服務可以使用不同的程式語言，不同的儲存介質，來保持低限度的集中式管理。下面這張圖，很好的說明了單體架構和微服務架構的區別。
根據 Choerodon 豬齒魚的開發實踐和產品化經驗，在網際網路+、雲端計算和大資料、人工智慧等的大背景下，構建軟體系統產品，首先要把系統的基礎框架搭好，方便後續的擴充套件。而微服務架的獨立部署、鬆耦合等特點，與Choerodon豬齒魚的想法和設計理念不謀而合， 所以 Choerodon 最終選擇了微服務架構作為基礎架構。
而在微服務基礎框架中，有兩個不得不提的微服務架構，分別是阿里巴巴的 Dubbo 和 Pivotal 公司開源的 Spring Cloud 。
Dubbo的誕生背景
Dubbo 是一個高效能、基於JAVA 的開源RPC 框架。阿里巴巴開源的 Dubbo 致力於提供高效能和透明化的RPC 遠端服務呼叫方案，以及SOA 服務治理方案，使得應用可通過高效能RPC 實現服務的輸出和輸入功能，和 Spring 框架可以無縫整合。本質上而言，是一個服務框架。根據Dubbo 的官方 Roadmap 可以看到，Dubbo 的發展經歷瞭如下幾個過程：
- 資料訪問框架（ORM）：早期的主流開發方式是物件導向的開發方式。只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。關聯式資料庫是企業級應用環境中永久存放資料的主流資料儲存系統，簡化了增刪改查工作量。
- Web框架(MVC)：隨著訪問量逐漸增大，單一應用已經無法滿足業務需求，將應用拆分成互不相干的幾個應用，分離檢視層和業務邏輯層以提升效率。
- 分散式服務框架(RPC) ：當垂直應用越來越多，應用之間互動不可避免，將業務抽取出來，作為獨立的服務，逐漸形成穩定的分散式服務架構。
- 面向服務的架構(SOA)：當服務越來越多，業務和環境的變化越來越快時，對於資源的控制，效能的要求也就越發重要。SOA 將一個應用程式的業務邏輯或某些單獨的功能模組化並作為服務呈現給消費者或客戶端，使得業務IT 系統變得更加靈活。
Dubbo 按照分層來規劃我們的系統，包含遠端通訊、叢集容錯和自動發現三個核心部分。提供透明化的遠端方法呼叫，使各個服務之間解耦合，並通過RPC的呼叫來實現服務的呼叫。
Dubbo 由於自身的設計使得服務之間的呼叫更加透明，網路消耗小，同時藉助類似zookeeper 等分散式協調服務實現了服務註冊。但是Dubbo 的缺點也是顯而易見的，比如：
- 只支援JAVA 使得Dubbo 在開發語言上受到了限制
- 雖然RPC 相對於HTTP 而言效能更高，但是在網路通用性上卻有著侷限性
- 而且對於一個微服務架構而言，包括服務閘道器，配置中心等很多東西都是缺失的，需要自己實現
- 雖然Dubbo 很早就進行了開源，但是在很長一段時間官方都沒有對開源版本進行維護
由於這些缺點，Choerodon 並沒有選擇 Dubbo 作為基礎開發框架。
Spring Cloud 應運而生
在微服務架構的概念提出之後，很快 Netflix 公司將自家經過多年大規模生產驗證的微服務架構，抽象落地形成 一整套開源的微服務基礎元件 NetflixOSS 。2015年，Pivotal 將 NetflixOSS 開源微服務元件整合到其 Spring 體 系，並推出 Spring Cloud 微服務開發技術棧。自此，微服務技術迅猛普及，甚至 Spring Cloud一度成為了微服務的代名詞。
可能更多瞭解微服務架構的讀者都是從 Spring Cloud 入門，憑藉之前 Spring Framework 的良好群眾基礎和Cloud 這個具有時代感的名字，Spring Cloud 的名字可以說是無人不知，無人不曉。結合Pivotal 公司的 Spring Boot，我們通過封裝開源成熟的Spring Cloud 元件和一些基礎的分散式基礎服務，就可以簡單快速的實現一個微服務框架，降低應用微服務化的門檻。
Spring Cloud 提出了一整套有關於微服務框架的解決方案。包括：
- 服務註冊發現：Spring Cloud Eureka
- 負載均衡：Spring Cloud Netflix
- 服務閘道器：Spring Cloud Zuul
- 配置管理：Spring Cloud Config
- 服務消費: Spring Cloud Ribbon/Feign
- 分散式追蹤：Spring Cloud Sleuth
- 服務容錯：Spring Cloud Hystrix
- ...
下圖說明了藉助Spring Cloud 搭建的一套簡單的微服務體系。
可以看到，Spring Cloud 整合了眾多元件，從技術架構上降低了對大型系統構建的要求，使架構師以非常低的成本（技術或者硬體）搭建一套高效、分散式、容錯的平臺。但同時，在實際開發中也發現 Spring Cloud 存在著的一些問題：
- 技術要求高：Spring Cloud 對於配置中心、熔斷降級、分散式追蹤、在許可權認證、分散式事物等基本的功能，並沒有提供一個成熟的元件，需要結合第三方的元件或自研實現。這對整個開發團隊提出了非常高的技術要求。
- 程式碼侵入性強：Spring Cloud 對業務程式碼有一定的侵入性，技術升級替換成本高，導致實施團隊配合意願低，微服務落地困難。
- 服務運維困難：Spring Cloud 在服務排程和部署、服務日誌、服務監控等仍有缺失。當服務的規模增大，對於微服務的管理有可能會增加運維的負擔。
- 多語言支援不足：對於大型公司而言，尤其是快速發展的網際網路公司，企業的性質決定了多語言的技術棧、跨語言的服務呼叫也是常態，跨語言呼叫也恰恰是微服務概念誕生之初的要實現的一個重要特性之一。
Dubbo & Spring Cloud 對比
對比Dubbo 和Spring Cloud 可以發現，Dubbo 只是實現了服務治理，而Spring Cloud 的子專案則分別覆蓋了微服務架構下的眾多元件，而服務治理只是其中的一個方面。
通過谷歌和百度的搜尋統計可以看到，自2015年起到現在，國內對於Spring Cloud 檢索指數也在逐漸趕超Dubbo。
綜合而言，Dubbo專注於服務治理；Spring Cloud關注於微服務架構生態。
雖然 Spring Cloud 降低了微服務化的門檻，但是除了基礎的服務發現以外，Choerodon 團隊在實際開發中也遇到了諸多的挑戰。例如，各個元件並非完美無缺，很多元件在實際應用中都存在諸多不足和缺陷。 Spring Cloud 並不是銀彈，微服務架構解決了單體系統變得龐大臃腫之後產生的難以維護的問題，但是也因為服務的拆分引發了諸多原本在單體應用中沒有的問題，比如部署困難，監控困難，運維成本大，是選擇 Spring Cloud 首先要面對的問題。
而容器化的普及，尤其是雲原生技術生態的不斷完善，比較好地解決了微服務架構的採用引發的諸多問題，使得微服務在普通傳統企業的落地成為了可能。
Kubernetes + Docker 使微服務實施成為一種可能
當企業逐步接受微服務架構，享受著微服務帶來好處的同時，也面臨著微服務運維成本的增加， 環境的不一致，服務的編排、部署、遷移等諸多問題。Choerodon 平臺經過不斷地演進，從初期引入Docker，到Rancher + Jenkins，再到現在採用 Kubernetes 為容器編排和管理工具。
容器技術產生的主要原因，並不是因為資源浪費。主要是開發和運維人員環境不一致，導致開發效率大大降低。通過容器可以在一個完全隔離的環境中非常高效地執行程式碼，容器化天然適用於微服務，改善了引入Spring Cloud 微服務後開發效率大大降低的問題。但是單獨使用Docker 並沒有完整的解決微服務管理的痛點，服務的部署和運維仍然急需解決。
Kubernetes 是谷歌推出的容器編排引擎，是基於GoLang 實現的一個開源軟體。K8s（Kubernetes）初源於谷歌內部的Borg，提供了面向應用的容器叢集部署和管理系統，其目標旨在消除編排物理/虛擬計算、網路和儲存基礎設施的負擔，並使應用程式運營商和開發人員完全將重點放在以容器為中心的原語上進行自助運營。
早期大家對於K8s 定位是容器編排引擎，同一時期流行的容器編排引擎還有MESOS、Docker Swarm 等。但是經過幾年的發展，K8s 已經成為了雲供應商的通用基礎設施，我們熟悉的Google Cloud，AWS，Microsoft Azure，阿里雲，華為雲等等，都提供了對K8s 的支援。現在，K8s 已經不僅僅是一種工具，更多的是作為微服務架構的一種行業標準。
下圖通過使用微服務架構的設計思想來看待K8s，並對K8s 中的一些功能進行了說明。
通過對比可以看到，在設計上，K8s本身就屬於微服務架構的範疇。這裡有的人可能就會有疑問，既然 K8s 功能這麼強大，那麼K8s 和 Spring Cloud 到底哪個更好？Choerodon 為什麼不直接使用Kubernetes 作為基礎的微服務架構呢？
為了區分Spring Cloud 和Kubernetes 兩個專案的範圍，下面這張圖列出了幾乎是端到端的微服務架構需求，從底層的硬體到上層的 DevOps 和自服務經驗，並且列出瞭如何關聯到Spring Cloud 和Kubernetes 平臺。
可以看到：
- Spring Cloud：自上而下，面向開發者，從應用程式碼到微服務架構的方方面面
- Kubernetes：自下而上，面向基礎設施，試圖將微服務的問題在平臺層解決，對開發者遮蔽複雜性
綜上對比，K8s 遵循了微服務架構的基本核心要素，雖然在一些功能上有所欠缺，但不可否認，K8s 幫助補足了使用Spring Cloud 所缺失的一部分。
微服務“新秀”--Service Mesh
Choerodon 通過使用 Spring Cloud + Kubernetes 的模式，幫我們能夠很容易的構建和部署微服務架構。但是線上上管理整個微服務體系的時候，仍然面臨著一些難點。
一直以來都存在一個謬誤，那就是在分散式系統中網路是可靠的。實際上網路是不可靠的，也是不安全的，微服務中大部分的故障都是出現在服務通訊中。
K8s 幫我們實現了微服務的部署，但服務的網路呼叫、限流、熔斷和監控這些問題，依舊讓開發和運維人員都十分頭痛。如何保證應用呼叫和事務的安全性與可靠性？Service Mesh 由此應運而生。
在過去幾個月裡，Service Mesh是行業內毋庸置疑的焦點。Service Mesh 譯作“服務網格”或“服務柵格”，作為服務間通訊的基礎設施層。Service Mesh 是一種模式，而非技術。Buoyant 公司的 CEO Willian Morgan 在他的文章《WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?》中解釋了什麼是 Service Mesh。
A service mesh is a dedicated infrastructure layer for handling service-to-service communication It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.*
Service Mesh 本質上是一個輕量級的網路代理，好比應用程式或者說微服務間的 TCP/IP。
對於開發人員而言，在編寫應用的時候無需關心網路這一層，使得服務迴歸到本質，專注於業務功能，服務中的互動則交給Service Mesh。Service Mesh 為服務提供了一個檢視，提高了追蹤能力，並提供了新增跟蹤而不觸及所有應用的能力，也就是所謂的Service Mesh 程式碼無侵入和透明性，能夠幫助團隊更好地管理服務。
Service Mesh 架構圖：
可以看到，Service Mesh 通過一種Sidecar的模式。給每一個微服務例項部署一個Sidecar Proxy。該Sidecar Proxy 負責接管對應服務的入流量和出流量，並將微服務架構中的服務訂閱、服務發現、熔斷、限流、降級、 分散式跟蹤等功能從服務中抽離到該Proxy 中。
Sidecar 以一個獨立的程式啟動，可以每臺宿主機共用同一個Sidecar 程式，也可以每個應用獨佔一個Sidecar 程式。所有的服務治理功能，都由Sidecar 接管，應用的對外訪問僅需要訪問Sidecar 即可。當該Sidecar 在微服務中大量部署時，這些Sidecar 節點自然就形成了一個服務網格。
通過控制面元件對這些服務網格進行管理，這樣也就提供了一種對於微服務進行高效而統一的管理方式。集中化的控制皮膚，同時仍然具有隨心所欲的敏捷性和基於雲的應用開發。這一特性，使得Service Mesh 成為大勢所趨。
總 結
回顧微服務結構發展的這幾年，微服務架構的逐漸普及，容器技術的興起，雲原生的趨勢，微服務技術生態在不斷地變化中，容器、Cloud Native、Serverless、Service Mesh，Knative 等新技術新理念你方唱罷我登場，使得整個以微服務為核心的生態越來越完善成熟。
像在前文中提到的Kubernetes、Service Mesh等都是解決微服務架構本身系統範圍的問題，紮實可靠的基礎框架，有利於後續的開發，這也是產品研發、系統實施的關鍵第一步。
除了系統本身的技術棧，工程落地實施是另一個要解決的問題。很多產品開始開發的時候，都不太注意規範化，待產品需求越來越複雜，人員越來越多時，整個專案會變得很難維護，甚至會影響產品的持續迭代。特別是微服務技術體系的引入，這個問題會更加明顯。所以如果專案一開始，就以工程化的思想去組織程式碼，以規範化的流程去做構建釋出，會給後續的發展打下堅實的基礎。微服務的工程落地實施是Choerodon豬齒魚一直關注和實踐的方向，通過整合DevOps工具鏈和引入落地敏捷實施的方法論，讓微服務架構的工程落地變得容易，這也成了Choerodon的PaaS平臺能力，在這就不做贅述，感興趣的讀者可以到Choerodon的官網瞭解（choerodon.io）。
關於Choerodon豬齒魚
Choerodon豬齒魚是一個開源企業服務平臺，是基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、資料、智慧洞察、企業應用市場等業務元件，致力幫助企業聚焦於業務，加速數字化轉型。
歡迎大家通過以下社群途徑瞭解豬齒魚的最新動態、產品特性，以及參與社群貢獻：
- 官網：choerodon.io
- 論壇：forum.choerodon.io
- Github：github.com/choerodon/
- 微信公眾號：Choerodon豬齒魚
- 微博公眾號：Choerodon豬齒魚
歡迎加入Choerodon豬齒魚社群，共同為企業數字化服務打造一個開放的生態平臺。