微服務是一個很大的概念，從團隊組織到佳實踐似乎都有實施微服務的一些指導。我們這里只提構建微服務的架構模式，也就是關乎到你用什么樣的方式來構建你以微服務架構來組織的應用系統。
近些年隨著微服務的火熱，越來越多的團隊開始進行實踐，將微服務紛紛落地，也許你是從0開始，一步步地完成了單體應用向微服務的改造，讓我們來看看，你解決了多少問題。
微服務將原本內存中函數的調用轉換為網絡中的調用后，就牽扯到這些問題，而任何一個分支展開，都會涉及一系列的問題。業務開發者也許真的有精力去學習架構相關的復雜問題，然而對于公司來說，真正有價值的是業務本身，讓業務開發者解決這些問題需要花費浪費大量的時間精力，導致業務上線受到影響。那我們來看看是否有便捷的方式來解決業務開發者的痛點。
一句話來概括：一種語言開發框架來作為微服務開發的底座，封裝掉復雜性，幫助你解決跨網絡帶來的問題，讓用戶聚焦在上層業務邏輯的開發。通常情況下會實現以下功能：
現在我們來看看業界有哪些可用的Chassis框架
先不細去糾結微服務的嚴格定義，也先暫且擱置諸如“某些老舊框架是否是真的微服務框架”這類爭議，從實現方式來看，上述服務化框架都是將分布式系統開發的復雜性進行了一定程度的封裝然后提供了簡便的開發接口供使用者調用。但是，用這種方式構建微服務還有一些問題：
我們知道技術演進來自于在實踐中不斷地將功能抽象，解耦，封裝，服務化。
在引入后面內容前，我先介紹下SideCar模式
一個典型的場景如下:
應用容器與日志同步工具在同一個Pod下，共享存儲卷，應用程序生成的日志文件會由日志同步工具收集并發送到類似kafka，elasticsearch這樣服務中。
在這樣的架構下我們獲得了什么呢？
在這個模式的基礎之下，我們引入了Service mesh。
Service mesh早是由Linkerd給出的定義，我們來看看英文版:
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. (But there are variations to this idea, as we’ll see.)
The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability.
大致的意思如下：
依然沒有銀彈，我們來看看Service mesh解決不了的問題
代： 基于NGINX的微服務代理
該平臺是華為公司內部使用的微服務開發部署運行平臺，開發于2013年，用于公司內部某電信業務。在這個業務系統中有大概400多個左右的微服務，實例數量根據局點大小不一樣，一個典型的部署為800多個左右實例的規模。
整體架構如下：
其中的Internal Router組件用來給開發者解決分布式架構中的可靠傳輸問題：
用這種方式構建的微服務環境已經在超過200個局點的生產環境下得到使用，整體運行情況良好。但是隨著時間的推移，當業務對敏捷的要求越來越大，而且容器的使用也越來越廣泛，這種方式帶來了一些問題：
為了解決這些問題，出現了第二代的解決方案： HSA Sidecar
HSA是華為內部的一套微服務開發框架，它提供了注冊中心，配置中心，java開發框架，以及SideCar等組件
雖然代的問題解決了，但是第二代的Sidecar在性能和資源占用上有很大的問題，在少量的技術項目中試用后，因為資源占用過高的問題無法在大規模環境中推廣使用。
Service Mesh 模式的一種實現。基于自研的Go語言微服務框架（該框架即將開源）開發，使用ServiceComb注冊中心（已經開源）與CSE配置中心，以Sidecar的方式部署在微服務所運行的環境中，也可以PerHost模式運行。在用戶數據面使用，提供VM部署、公有云部署、容器部署，占用資源小（閑置10多M，并發運行時30多M）。
注冊發現
注冊中心為插件化模塊，目前對接了ServiceComb、Service Center，未來還會有更多的系統對接進來
路由規則管理
根據預定義的路由規則對請求進行引流
協議轉換與不同框架的對接與統一治理
使用標準OpenAPI契約，可以實現Dubbo RPC協議與Http協議的互轉，用于透明地接入遺留的Dubbo應用并對遺留應用進行統一的服務治理
使用負載均衡與重試策略
使用熔斷降級
熔斷使用的斷路器對一個執行過程進行包裝，斷路器負責監控維護每個執行過程的狀態、結果、錯誤、超時。當達到一定閥值時就會熔斷，并觸發降級。以這樣的機制來保護服務提供者，不會出現級聯的雪崩式錯誤。
使用限流
提供了消費者端與提供者端限流
用戶可以通過配置來限制每秒只允許多少個請求被發出或者接受
對接監控
Metrics：提供了主動上報到CSE Dashborad的方式。也可與華為公有云APM，Prometeus對接
分布式追蹤：對接Zipkin
整體架構
Mesher背靠CSE組件，使用微服務引擎中的服務中心與配置中心等服務作為控制面，Mesher與業務代碼部署在一起運行在數據面
數據面
即Service mesh組件本身，對所有請求進行處理，它有以下功能
控制面
為管理人員提供統一的管理入口，為所有運行的mesher提供配置下發但不會介入服務請求
不同的部署方式
與業務服務部署在一起有3種運行模式
1.僅消費者使用Mesher，提供者為使用ServiceComb開發框架的服務或者裸服務，
下圖為例:
ServiceC為裸服務,它既不用mesher也不用SDK，那么起碼它需要自己注冊到服務中心中，供其它服務發現，否則無法進行訪問。
2.消費者與提供者均使用Mesher
以這種方式運行的服務可以使用透明TLS傳輸，并且擁有了服務端限流
3.提供者使用Mesher，消費者A使用ServiceComb SDK進行開發可直接發現服務B，但是消費者C作為裸服務需要自己發現服務B
運行時請求處理
消費者端請求
上圖為例：
SockShop服務將mesher作為代理并使用地址http://order/list訪問訂單服務
上圖為收到遠程請求后的處理過程
在性能對比后，我聊下自己的看法
現在已經出現了越來越多的Service mesh實現：
Linkerd 是在2016年出現的，Envoy在6個月后出現，不過Envoy已經在2015年就商用了。這兩個項目也是有名的Service Mesh。
Istio在2017年5月出現，它提供了控制面，并使用Envoy作為數據面的Service Mesh。目前已經開始有些Service Mesh提供者宣布與Istio進行集成，比如Linkerd和Nginx。這意味著控制面與數據面是解耦的，任何的控制面都可以和數據面Service Mesh進行集成。CSE Mesher也會考慮與Istio進行集成，成為除了Envoy之外的另一種數據面選擇。
實際上在開源項目之外，很多公司內部也早已用類似的方案進行自己系統的構建，各自有各自的特點用來解決自己的實際問題。Istio成為CNCF里面一個被認為是“Kubernetes之后的第二個爆款”是有理由的，它提供了一種從平臺的角度解決應用架構的思路，進一步簡化了應用的開發。我們也相信在這個大舞臺上會有更多的方案出現，而這些方案的出現也會讓微服務和Cloud Native應用的構建方式有更多地選擇。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
