Choerodon的微服務之路(一)：如何邁出關鍵的第一步

在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 豬齒魚做爲開源多雲應用敏捷全鏈路技術平臺，是基於開源技術Kubernetes，Istio，knative，Gitlab，Spring Cloud來實現本地和雲端環境的集成，實現企業多雲/混合雲應用環境的一致性。平臺經過提供精益敏捷、持續交付、容器環境、微服務、DevOps等能力來幫助組織團隊來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。

更加詳細的內容，請參閱Release Notes和官網。

你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

• 官網：http://choerodon.io
• 論壇：http://forum.choerodon.io
• Github：https://github.com/choerodon

歡迎加入Choerodon豬齒魚社區，共同爲企業數字化服務打造一個開放的生態平臺。

本篇文章出自 Choerodon豬齒魚社區董凡。