致微服務開發者和開源志願者的一封信
------寫在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等開源微服務領域項目的支持協同；
- 開源社、CSDN、開源中國、InfoQ等社區和媒體的支持等；
- 華為消費者雲、雲 EI、雲安全、雲核，軟通動力，文思海輝，互靈物聯，奇蛙無人機，梅斯醫藥，杭嶺科技，高邁致遠等一批夥伴用戶的支持。
開源的力量是無窮的，ServiceComb的點點滴滴前進來自方方面面支持，感謝開源志願者們的一如既往，才有了ServiceComb社區的踏實前進。
[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/
閱讀更多 ServiceComb 的文章
