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

在豬齒魚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的官網了解，

本文由豬齒魚技術團隊原創，轉載請注明出處

標籤：其他

上一篇：云計算 = “潘多拉”？

下一篇：【論文筆記】Recommendations as Treatments: Debiasing Learning and Evaluation