2018年6月25日，開源介面盛會LC3上，華為繼去年開源微服務方案ServiceComb後，又宣佈將於7月份開源微服務領域服務網格ServiceMesh產品化技術Mesher。

 ServiceComb社群憑藉與華為雲的源頭關係，獲得關於Mesher的第一手資訊：

• 華為雲是最早將Service Mesh產品化商用的企業之一，旨在將微服務中的應用問題和網路問題分離。
• 當前華為雲AI和文思海輝樓宇設施管理服務等業務已經使用Mesher進行商用。 
• Mesher還具備基礎設施完全解耦，高效能，侵入式與非侵入式治理互通，可擴充套件三方SDK等特點。

Mesher開源後，將會如何運作，進入哪個基金會，是否會進入ServiceComb，這些是當前業界最為關注的事情，ServiceComb目前能提供的資訊也僅是這些。但是ServiceComb與開源後的Mesher一衣帶水，不論Mesher是否進入ServiceComb，ServiceComb都將會竭盡所能幫助Mesher建立熱衷和忠誠開源的品質，為開源社群營造好的土壤貢獻力量。

對於關於ServiceComb對於Service Mesh和 Mesher的思考，在下面《ServiceComb社群在其開源一週年之際寫給微服務開發者的一封信》已經有了相關表述：

 

寫在ServiceComb開源一週年之際

2018年6月25日，開源界盛會LC3（LinuxCon + ContainerCon + CloudOpen）在北京拉開帷幕，一年前，同樣在LC3大會上，ServiceComb由華為雲微服務引擎服務開源，ServiceComb和蜂巢Logo一起正式走入開源和微服務領域。

回望過去，ServiceComb於17年12月由華為雲捐贈給了Apache軟體基金會，成為國內第一個進入Apache孵化的微服務專案，累計貢獻給Apache社群33萬多行程式碼，釋出1.0.0-m1和1.0.0-m2共6個孵化器軟體版本，使用使用者覆蓋到了IoT、生物醫藥、金融、網際網路、地產、AI等行業。

 

在這裡，尊重、誠實、專注、透明決策、開放……，社群日漸活躍和健康，正穩步踐行“Apache Way”。細細盤點過去一年，我們發現，ServiceComb正在一步一個腳印實現著社群夥伴們對於微服務的堅持——“通過微服務解決方案解放使用者和開發者”。

 

ServiceComb從哪裡來

ServiceComb 源自華為雲微服務引擎，主體程式碼由華為雲捐贈，致力於幫助企業輕鬆構建雲原生應用及傳統企業業務快速微服務化，通過系列解決方案幫助使用者快速開發微服務的同時實現對這些微服務應用的高效運維管理。華為雲微服務引擎在華為內部系統商用了3年多時間，通過“吃自己的狗糧”的方式在保持電信行業高效能低時延能力的同時也歷經了華為VMALL商城等電商場景的歷練。

例 如

華為消費者雲業務擁有數億級使用者訪問量，業務對效能和時延等要求都非常高，曾嘗試使用其他分散式框架實現，由於大部分業務是I/O密集型的，同步微服務呼叫模式導致CPU利用率低，效能也無法提升，硬體資源利用率低。 採用ServiceComb的Reactive全非同步模式之後，QPS提升2倍+、時延降低45%，大量的硬體資源因此被節省，並非同步模式同時解決了傳統分散式框架經常遇到的雪崩效應，即某個微服務呼叫慢導致上游呼叫方被阻塞引起雪崩。可以說，在誕生伊始，ServiceComb就把高效能放在了首要位置進行設計開發。

 

高效能的微服務框架

近幾年的發展，微服務逐漸普及，並且開始應用於雲上業務的核心元件。這就要求微服務框架能夠在這種場景下，保證系統的資源佔用、時延等效能指標能夠滿足業務系統的需求，而業務執行緒利用率低，超時時間配置過長導致成功率低和雪崩效應是微服務化中的最嚴峻問題，故當前開源領域的微服務或分散式框架都正在競相盡全力支援非同步核心中。

高效能

ServiceComb在設計之初就將Vertx作為非同步呼叫的核心，實現同異步可選。當業務程式碼也使用非同步模型時，業務邏輯直接在Eventloop中執行，整個業務流程中沒有執行緒切換，所有的等待邏輯都是非同步的，只要有任務，則不會讓執行緒停下來，充分、有效地利用系統資源並提高系統吞吐能力。

全非同步核心之非同步呼叫

在電商、網際網路、IoT等新興領域中，長流程或複雜業務流程是很常見的，這就造成了一個消費端需要呼叫多個微服務進行業務邏輯編排或者多個微服務進行級聯的場景。

另外一種的型別，業務本身對服務呼叫的時延不敏感，傳統的手段是採取同步呼叫並設定大的超時時間來處理，這種實現方法將會導致在業務高峰期時延達到超時閥值時系統被輕易壓垮。

ServiceComb的非同步核心特點在以上場景的實際業務中都發揮了充分的價值，在電商和IoT兩個實際業務中TPS提升約50%，CPU佔用率下降50%，時延降低約30%，這將意味著ServiceComb幫助使用者節約近一半的硬體資源，也有效防止了微服務領域最易面臨的雪崩效應。

全非同步核心之同步呼叫

在業務使用同步模型時（既存系統改造等場景），ServiceComb進行了多項優化以減少系統各元件的阻塞。

1

 在微服務程序中，為傳輸層建立獨立的Vertx例項。

2

為每個連線額外配備一個CAS訊息佇列，將所有訊息儲存到CAS佇列中，減少入隊競爭。通過原子變數判定，只有入隊前CAS佇列為空，才向Eventloop下發寫任務，喚醒Eventloop執行緒。

3

允許通過配置，在服務提供者和消費者之間建立多條連線，充分利用硬體資源。

4

在服務提供者端，支援隔離倉技術，實現故障隔離。為不同的業務進分組，並配置不同的執行緒池，解決不同處理速度的業務邏輯在同一個執行緒池中造成的業務整體效能下降問題。支援在程序、介面、方法三個級別進行執行緒池配置。

在第三方個人的評估報告中，ServiceComb的同步服務呼叫在當前主流的微服務和分散式框架中效能排在前列。

一站式開箱即用微服務解決方案

PaaS先驅Heroku公司的CTO Adam Wiggins 為實現軟體即服務提出微服務12要素，以從軟體設計、開發到運維的整體端到端角度思考程式的架構演進。

一直嚴格遵循微服務原則

在ServiceComb前身華為雲微服務引擎出現之前，公司也有部分業務和眾多企業一樣，嘗試了各樣雲原生微服務化方案，時至今日，我們也依舊可以在網路上見到眾多如“A+B+C實現微服務框架”的文章，也見到各類開源RPC框架正在緊鑼密鼓支援微服務化中。

ServiceComb，一站式的微服務解決方案，其前身華為微服務引擎的設計就已經嚴格遵循微服務原則，開源之後更是堅持力求在設計、開發、運維方面都給使用者及開發者以最佳的體驗，同樣投入下獲取更多的產出。

ServiceComb提供包括JAXRS、SpringMVC和透明RPC在內的多樣化的程式設計風格。使得程式設計師在使用微服務框架時能夠保持自己的習慣。

OpenAPI

OpenAPI吸收了大量的跨語言經驗，可在不同語言之間進行解析。ServiceComb圍繞OpenAPI開源生態和Swagger工具，以服務化契約為中心構建，可通過編寫程式碼或編寫介面實現契約，契約先行支援自動生成程式碼，自動生成介面文件，自動生成測試樁程式碼和擋板程式等。ServiceComb同時支援REST協議和二進位制私有Highway通訊協議，且可通過修改配置檔案和註解的方式輕鬆的切換，在構建業務系統時，可以根據需要和測試結果，進行靈活的選擇。ServiceComb的治理結構也圍繞服務化契約構建，基於ServiceComb及ServiceComb支援的工具，業務可在設計和開發階段保持開發者習慣的前提下輕鬆實現微服務自治及鬆耦合。

ServiceComb內建

ServiceComb內建輕量級高效能邊緣服務，支援Producer端治理，結合擴充套件路由能力和動態配置能力能輕鬆實現灰度釋出、A/B測試等關鍵特性，在業務實測中，在同等資源使用下吞吐能力是業界常規方案的2.8倍。

ServiceComb內建覆蓋了微服務下絕大多數場景的流量控制、容錯熔斷、限流降級、故障注入等治理和管控能力。內建支援包括RoundRobin、Random、WeightedResponseTime、SessionStickiness在內的豐富的負載均衡策略，與服務中心ServiceCenter配合，實時感知微服務例項的狀態變化，靈敏調節負載。

APM

APM在微服務領域用於幫助理解系統行為、用於分析效能問題。ServiceComb從Metrics、Tracing和Log三方面全面支援APM，內建的Metrics包含基本資源使用、呼叫次數、時延和TPS等關鍵指標，支援HttpCode、Consumer/Producer等豐富的維度用於資料二次聚合；Tracing無縫對接主流的Zipkin和新興的SkyWalking；微服務執行的關鍵資訊也將無需使用者配置自動寫入日誌。動態配置、優雅停機、事件通知等機制也被ServiceComb優雅內建。

一站式開箱即用

如果把開發一個微服務應用比作買房的話，傳統的微服務或分散式框架提供的是“毛坯房”，從收房到入住還要經歷辛苦的裝修過程。而ServiceComb提供的則是“精裝修房”，不求覆蓋最全，只求配合最好，體驗最舒適，讓使用者或開發者能夠“拎包入住”。

 

例如建立一個CRM應用，真實業務下會設計拆分出十幾個甚至更多的微服務，為了讓這些微服務能夠很好地在一起工作，通常需要使用者逐個學習對應所需元件、新增依賴、分別進行配置，選擇哪些元件?怎麼用?如何新增依賴？裁剪時依賴對應哪些功能？版本之間是什麼關係？版本衝突如何解決？諸如此類一系列的問題都會讓開發者特別是初學者頭痛不已。

 

相比而言，ServiceComb java-chassis-dependencies集中管理了所有必須的依賴，start.servicecomb.io生成出來的專案既包含示例程式碼，也包含必要配置的以及微服務治理所需的配置，批量生成所有的微服務後，使用者只需要專注於填充業務程式碼。完成開發後，部署ServiceCenter，啟動微服務，一個良好的CRM系統就運轉起來了，之後只需要專注於運維，後期也可通過動態配置，隨時修改配置值調整治理能力。在整個過程中，ServiceComb堅持“約定大於配置、集中配置”，一切化繁為簡，拒絕凌亂。使用ServiceComb可以在30分鐘內開發出一個雛形的CRM應用。

ServiceComb一站式開箱即用，嚴格遵守微服務原則，夥伴使用者軟通動力使用ServiceComb從設計維度解決業務互動複雜引入的程式碼重複度高和大型應用部署困難等陣痛，新型創業公司奇蛙無人機更是能夠一天之內從傳統分散式框架遷移到ServiceComb。

ServiecComb並沒有為了減輕使用者和開發者負擔而封鎖自己的設計，那樣將無異於讓使用者住進了牢房，雖然衣來伸手飯來張口卻沒有了自由，而是為了讓業務能夠定製化自己的特別需要、方案長足發展和吸收如SpringCloud等優秀元件的精華，ServiceComb堅持了開放性設計，消費者和生產者程式設計模型可擴充套件，通過治理鏈可擴充套件治理能力，通訊協議可擴充套件，並可開放對接到其他的註冊服務、配置服務等三方元件，可既輕量級運行於Netty Http之上，也可作為一個Servlet運行於Web容器裡。

協同開源力量攻克微服務難題

在微服務架構下，應用通常是由一組鬆耦合的相互協調的服務所組成，每個服務獨立使用自己的資料庫。在缺少一個統一的資料庫來提供事務一致性的前提下，如何協調各服務之間的分散式事務，是微服務化的過程中所面臨的一大難題。ServiceComb提供了Saga子專案，在理論指導下，正協同社群力量在不斷研究好的方法和實踐來解決這個難題。

Saga

Saga來源於資料庫處理長時事務一致性處理論文， 一個長時事務是又多個本地務組成，每個本地事務提供了執行以及執行失敗補償兩個方法。

Saga通過協調系列本地事務執行（事務執行失敗會呼叫相關補償方法來恢復原有狀態），來證長時事務執行的一致性。與現在主流的TCC模式相比，ServiceComb saga對業務邏輯侵入小，且效能更高。在過去的一年中，ServiceComb Saga完成了從“集中式”到“分散式結合集中式的”演進，支援了通過註解標註Saga對應子事務資訊。未來，ServiceComb saga將在多租戶服務支援、訊息佇列傳遞事件資訊等方面繼續提升，朝著“更好用、更高效”的方向努力。

ServiceComb要到哪裡去？

ServiceComb已開源一週年，越來越多的中國企業也陸續開源了其自研的分散式或微服務框架。ServiceComb試圖努力將全球最大的開源社群的精髓Apache Way帶入了中國企業的微服務領域，給開源開發者和企業使用者提供了更加親和的土壤。

未來已來

2018是服務網格元年，Service Mesh的出現，與ServiceComb致力於解放使用者和開發者的願景相匹配， ServiceComb一直在思考如何將Service Mesh理念更好地運用到微服務解決方案之中，當前已經有了一些雛形思路。喜訊是華為雲作為最早將Service Mesh產品化商用的企業之一，計劃於7月份開源名稱為Mesher的的高效能服務網格部件，旨在將微服務中的應用問題和網路問題分離，繼續為微服務開源的發展貢獻自己的力量。ServiceComb未來會繼續以完全開放的態度在服務網格技術維度和相應主流社群保持相容，吸納侵入式和非侵入式方案，作為完整的微服務解決方案在開源愛好者們和微服務從業者們的支援下散發光和熱，也期待社群志願者們和ServiceComb一道貢獻智慧。

 致謝  

過去的一年，眾多開源愛好者和微服務從業者們對ServiceComb給予了大力關注和支援，截至今日，大量開發者和使用者向社群專案提交了程式碼、貢獻了智慧、力量。以下致謝：

Roman Shaposhnik 等13名正式committer，Feng Zheng 等25名正式contributor，其他未在社群網站具名的支持者，包括但不限於：

•  Apache社群的支援；
• 已經向社群專案提交程式碼的大量開發者；
• 社群運營支援人員；
• SpringCloud、Skywalking等開源微服務領域專案的支援協同；
• 開源社等媒體和社群的支援等；
• 華為消費者雲、雲 EI、雲安全、雲核，軟通動力，文思海輝，互靈物聯，奇蛙無人機，梅斯醫藥，杭嶺科技，高邁致遠等一批夥伴使用者的支援。

 

開源的力量是無窮的，ServiceComb的點點滴滴前進來自方方面面支援，感謝開源志願者們的一如既往，才有了ServiceComb社群的踏實前進。

 

6月27日11:00~17:00直接前往國家會議中心211廳可直接參加LC3微服務Workshop，不用門票，不用門票，不用門票！！！
我在外地，沒辦法現場參加：沒關係，我們提供了視訊直播，直播地址：http://www.itdks.com/eventlist/detail/2294 

 

你將得到

兩位資深Apache Member對話的機會

華為雲微服務引擎原作者的深入解讀

使用者CTO 關於高效能高可靠的實踐分享

DDD專家現場佈道

炙手可熱的ServiceMesh技術劇透

 

  參考資料：  

[1] 如何設計一個優質的微服務框架 劉寶  

http://servicecomb.incubator.apache.org/cn/docs/open-design/

[2] Saga分散式事務解決方案與實踐 姜寧

http://servicecomb.incubator.apache.org/cn/docs/distributed-transactions-saga-implementation/

[3] RPC Benchmark Round 3魯小憨

https://www.jianshu.com/p/caf51f5cfbaa

[4] ServiceComb開發團隊

http://servicecomb.incubator.apache.org/cn/developers/team/