華爲雲繼ServiceComb後宣佈開源Mesher，微服務領域薪火不斷

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/