Apache 主席話開源之道，ServiceComb 微服務創新實踐解放開發者

Apache ServiceComb 項目成立已經 2 週年，一路以來，社區遵循 Apache Way，堅持中立、開放、多樣化的原則，攜手用戶和開發者長足健康發展。

2019 年，在認真聽取社區聲音後，社區推出 5 大創新新品項目，指望與用戶和開發者一塊兒思考如何共同去解決微服務中的難題，爲更好地回饋社區用戶和開發者，在 Apache 軟件基金會成立 20 週年之際，Apache ServiceComb 在 HC2019 華爲全聯接大會會場舉辦了「Apache 開源開發詳解」和「微服務創新實踐解放開發者」社區活動。本文回顧了這次活動中嘉賓的精彩分享內容，以及用戶和開發者聚焦的典型問題。

Apache 軟件基金會董事會主席 Craig Russell、Apache 孵化器管理委員會主席 Justin Mclean 兩位重磅嘉賓出席了這次活動，併爲中國的開源愛好者獨家剖析 Apache 的開源開發之道，對國內開源開發者、在校同窗在實踐中遇到的困惑給出了獨到的看法和建議。

同時，來自華爲的 Apache ServiceComb VP 姜寧、Apache ServiceComb 架構師馬彬、華爲雲 ServiceStage 架構師王啓軍爲你們分享了 ServiceComb 進入 Apache 的成長之路和趟過的那些坑、ServiceComb 面向用戶痛點創新的 5 個項目解讀、華爲雲 ServiceStage 在微服務自動化拆分工具的創新實踐，並對開發者關心的遺留應用向微服務轉型如何拆分數據庫 / 表、如何下降對底層開發框架的學習門檻快速實現微服務改造和開發、多廠商集成過程當中可能出現的異構服務如何互通，以及多語言如何實現微服務轉型等問題作了開放式的探討。

Apache 軟件基金會董事會主席 Craig Russell 話開源之道

Apache 之因此可以受到世界上衆多開源開發者的青睞，而且長盛不衰的緣由是什麼呢？Apache 軟件基金會董事會主席 Craig Russell 結合 Apache 的使命和 Apache 之道詮釋：

• Apache 是公益性組織，堅持「爲公衆利益提供免費的軟件」的使命，使用商業友好的 Apache 協議，讓整個世界的公衆從中獲益，並樂於接受全部人的捐贈。
• Apache 保持中立，不受任何企業或我的控制，注重構建社區而且爲這些社區提供項目管理服務，是「一個基於協做，一個基於交流和共同打造偉大的軟件的地方」。
• Apache 提供了對社區項目的治理之道 Apache Way，它讓社區和人們能夠攜手走在一塊兒，來追求一個共同的目標，其核心理念是「社區勝於代碼」，社區的位置放在首位，沒有獨裁者，由社區來決定什麼纔是正確的事情，而且每一個人均可以經過參與社區貢獻並得到功績。

Craig Russell 表示：Apache 爲衆多開源愛好者提供了廣闊的舞臺，中國做爲亞洲使用 Apache 軟件最活躍的國家，愈來愈多的公司或我的項目加入到 Apache 回饋社區，社區也在積極地回饋每一位貢獻者：免費的培訓和學習平臺，打造高質量的代碼，合做與競爭的雙贏平衡，而且使全部貢獻者受到法律保護。

Apache 軟件基金會孵化器主席 Justin Mclean 談成長爲 Apache 頂級項目之道

在認識 Apache 以後，項目如何進入 Apache 孵化器發展，並最終畢業成長爲世界頂級項目呢？Apache 軟件基金會孵化器主席 Justin Mclean 結合豐富的管理和實踐經驗，給出了很是中肯的建議：

• 圍繞項目創建社區，活躍的社區「能夠自我糾正，應對各類挑戰和問題」，社區溝通的原則倡導友善、尊重、信任和謙虛，Justin 表示：「咱們要信任，要假設其餘人都是有善意的」。
• 許可協議很是關鍵，它保障用戶使用軟件時不出現任何糾紛，同時也保護社區的商標、項目名字不被別人仿照，是合規性重要的一環，也是成爲頂級項目的必要條件。
• 發佈版本，爲了提供法律保護和發展社區，發佈的流程須要確保符合 Apache 的流程和規定，而且必須由 PMC 投票。
• 項目畢業，當一個項目具有自管理、獨立發佈的運做能力，並聽從 Apache 軟件基金會的規則，創建好法律框架，再也不須要孵化器組織或者導師的幫助，即知足從 Apache 孵化器畢業成爲頂級項目的條件。
  

Apache ServiceComb VP 聊項目成長之路和趟過的那些坑

做爲 Apache Member、Apache ServiceComb 首席技術專家，姜寧老師也曾擔任過 Apache RocketMQ 項目孵化階段的導師，有豐富的實戰經驗，姜寧老師爲你們分享了 ServiceComb 如何從零開始，並在 1 年內成長爲首個 Apache 微服務頂級項目的經驗：

• 與 Apache 導師保持充分交流很是重要，在導師豐富經驗的幫助下，能夠更快速地瞭解和適應 Apache 規則和流程。
• 充分利用好 Apache 郵件列表、JIRA 等公共的溝通渠道，讓更多的參與者瞭解項目、社區構建以及將來的規劃，郵件列表歸檔的功能也能使剛進入社區的貢獻者能快速找到每一個事情的上下文，融入社區。
• 項目捐贈給 Apache 以後，名字和商標不能在商業產品裏面隨便亂用。
• 按期舉行線上線下活動，爲社區的參與者和開源愛好者提供互相交流的平臺，有利於促進與其餘社區、項目之間的合做和推廣。
• 鼓勵你們參與，爲社區貢獻者留下適當的發揮空間，創建「幫扶」機制，讓更多的人可以參與進來，壯大社區。
• 抱着善意的心態去對待投票 -1，由於每一個 -1 意見都包含着參與者對社區的付出，而且從每次 -1 票中找出問題並改進。
  - 務必確保項目的每行代碼的來源是清楚的，沒有 copy right 和 license 的使用問題，這也是每次版本發佈前須要重點檢查的地方。
  

Apache ServiceComb 架構師解讀面向用戶微服務痛點的創新項目

衆所周知，微服務是一種架構理念，軟件架構極大依賴於專家經驗，而專家經驗更多地是依賴口口相傳或者文檔傳播，在企業向微服務轉型過程當中，有沒有相應的軟件或工具可以解放專家手腳、幫助開發者快速上手成爲用戶的關鍵痛點。

ServiceComb 進入 Apache 以來，認真聽取社區聲音，肯定了系列解決用戶微服務化過程當中痛點的方向，而且在社區裏面繼續創新孵化，於 2019 年推出 5 大新品項目解決微服務痛點問題，Apache ServiceComb 架構師馬彬解讀了 5 個新品項目面向的場景、現狀和下一步開發計劃：

• servicecomb-mesher，高性能服務網格框架，開箱即用、多語言、零侵入業務代碼實現微服務化改造。

愈來愈多的企業開始向微服務架構轉型，不一樣的企業使用的語言不一樣，甚至同一個企業因爲業務差別、聯合創新等因素，都有可能涉及使用不一樣的語言，而傳統的微服務開發框架具備業務侵入性特徵，沒法知足多語言場景、異構框架的服務治理互通訴求。

servicecomb-mesher 支持以 sidecar 的形態無業務侵入解決用戶在多語言場景下的痛點問題，而且其始終遵循開放式的設計，支持接入雲原生、運維、監控等流行生態，將來將在網關 / 生態 / 異構支撐等方面繼續探索，幫助用戶以最小化改造完成微服務轉型。

• servicecomb-toolkit，一鍵式微服務開發工具，自動化生成微服務工程、API、代碼、文檔，並支持 API 與代碼一致性校驗能力。

在集團型企業中，集成多個開發商應用的場景很常見，然而，不一樣的開發商存在開發語言、框架、習慣方面的差別，致使數據、服務標準不統一。

servicecomb-toolkit 幫助用戶快速構建基於 ServiceComb 和 SpringMVC/Jax-RS/RPC 等編程模型的微服務腳手架，提高遺留系統重構、全新微服務開發的效率，協同用戶實現基於標準 API 數據、服務標準化管控。將來 servicecomb-toolkit 將在支持一鍵製做基於 Spring Cloud 的微服務腳手架、OAI V3 規範、以插件集成到流行 IDE 方面作進一步的探索。

• servicecomb-service-center/syncer，對用戶透明的數據同步工具，使能異構、多服務中心數據互通。

多數據中心部署的企業，不一樣數據中心之間的服務數據如何互通？集成不一樣開發商的集團型企業，異構微服務開發框架實現的微服務如何互通？這些問題在傳統企業作微服務化選型或改造過程當中常常被說起。

ServiceComb syncer 爲此場景而設計，它提供數據同步能力，對用戶透明，對多服務中心提供對等網絡，並支持異構服務中心的數據轉換和同步，使基於不一樣微服務技術棧實現的業務能夠進行數據通訊。將來，syncer 將對跨雲、跨數據中心等場景提供更完善的支持。

• servicecomb-kie，語義型分佈式系統配置中心，使運維人員經過易於理解的數據和入口，管理複雜的分佈式系統配置。

傳統的配置中心，多使用 key:value 數據模型（如：ServiceB.user.getUser.timeout=10s），key 的規則只在該服務內生效，對於運維人員來講難以理解。並且隨着規則定義的不斷增加，key 也會愈來愈複雜，對用戶呈現也只有 key/value 單一視圖，影響了可讀性且不易於管理。

servicecomb-kie 經過支持 key(label):value 的數據模型設計改進了用戶配置方式（如：Timeout(service=serviceB, schema=user, operation=getUser)：10s），經過 key 和 label 的組合提高了用戶可讀性，方便擴展變動，而且支持生成多角度的配置視圖。將來，servicecomb-kie 配置中心將在數據加密、對接 k8s 生態等方面經過更多支持，使用戶更靈活選擇方案。

• servicecomb-fence，微服務認證鑑權框架，幫助用戶快速構建微服務的認證鑑權能力。

典型的互聯網應用不只須要訪問本應用的資源，還須要訪問第三方的資源，同時還提供接口給第三方使用。應用的接入形式是多樣化的，有手機，WEB 客戶端，API 訪問等。認證的方式包括用戶名密碼、手機驗證碼、人臉識別等。面對複雜場景，在微服務架構中，如何構建分佈式、安全和高效的認證鑑權機制是用戶關心的問題。

servicecomb-fence 提供開箱即用的標準化認證流程框架代碼，它結合 Oauth2.0 和 OpenID Connect 協議，實現 Oauth 4 種認證模型、Token 和 Session 組合的認證機制，支持微服務內部認證鑑權、對接第三方認證鑑權服務、爲第三方提供認證鑑權服務等應用場景，幫助用戶快速搭建高性能、安全的微服務認證鑑權能力。

華爲雲微服務架構師談「黑科技」微服務拆分創新實踐

華爲雲在 17 年將商用了 3 年的微服務框架 ServiceComb 徹底開源並捐贈給 Apache 以後，繼續基於 ServiceComb 在微服務應用平臺 ServiceStage 上提供商業雲服務，並持續投入與創新，做爲社區開發主力積極回饋社區。本次活動，華爲雲微服務架構師王啓軍爲你們帶來了解決用戶最關心的微服務拆分痛點問題的創新實踐。

• 微服務自動拆分工具
  

對於用戶和開發者來講，微服務改造第一大難題就是服務如何拆分。服務拆分須要考慮的方面不少，團隊大小、交付週期、業務方向、故障範圍、數據規模、吞吐量、一致性等都是影響拆分結果的因素，而且可能涉及業務、平臺、DBA、測試、運維等多職能部門的協同。

微服務拆分並非一個容易的工做，若是服務拆分不合理，會給用戶帶來服務數量爆炸而運維複雜、服務數量太少而不夠靈活、接口頻繁變動、系統架構複雜度提高等問題；若是是由經驗豐富的架構師們來拆分服務，問題可能會減小不少，可是時間、人力成本也會劇增，並且並不是全部的團隊都擁有有經驗的架構師。

綜上所言，服務拆分紅爲遺留應用向微服務轉型首要解決的難題。那麼，是否有可能經過自動化的工具來替代人去實現一些業務分析、拆分工做，從而解放開發者手腳，下降微服務入門門檻呢？從最關鍵的拆分數據庫 / 表的典型場景入手，華爲雲微服務團隊開啓了微服務自動拆分工具化的探索，經過從遺留應用中解析 DAO 對象、提取 SQL 語句和業務訪問日誌等客觀指標的方法，提供自動拆表、微服務建模和生成代碼的功能，工具具有的特徵：

• 當業務很複雜的時候，工具能夠幫助用戶自動梳理出業務邏輯和關聯度。
• 從數據庫中的表關聯關係和代碼中 model 的關聯關係咱們可以分析出表之間的關聯度。
• 從表中的數據量和訪問日誌咱們可以分析出業務的核心程度。

目前，微服務自動拆分工具已邁出第一步，具有做爲輔助性工具支持微服務拆分的輸入參考，後續將在支持蒐集和分析更多相關指標（好比研發人員的數量、產品將來的發展方向、交付週期等等這些比較主觀的因素）、提升自動化度、提升拆分精確度等方面作更深一步的探索和驗證。將來，但願將微服務拆分工具開源出來，聯合社區用戶和開發者力量共同發展。

「到底工具能不能代替人去拆分呢？是能的，之因此說不能，是由於指標不夠全面，不夠準確。當咱們掌握了足夠的指標以後，工具比人作的決策更準確。可是，如今咱們的指標尚未那麼全面，那麼準確，因此，如今工具更多的是輔助性的，可是，將來必定能夠作到」王啓軍表示。

主題演講精彩互動問答收錄

在主題演講結束後，現場與會的開源愛好者和微服務開發者與演講嘉賓進行了積極的互動交流，小編摘錄了社區用戶和開發者最關心的典型問題：

Q1: 在中國，人們習慣使用微信交流，而 Apache 基金會項目是須要使用郵件列表交流的。我想請問在發展新用戶的過程當中，須要怎樣處理這些習慣上的障礙？
Justin Mclean: 其實很容易的，我以爲項目決策是很重要的事情，它應該被記錄在郵件列表中。在郵件列表中探討和記錄問題，能夠作到有跡可循，有助於新加入的用戶瞭解項目。只要作到這一點，其餘都不是問題。

Q2: 做爲一個學生，如何參與一個開源小項目，有沒有什麼建議？
Justin Mclean: 首先要找到一個你感興趣的項目，項目裏通常會有相關的問題列表，你能夠從一些容易達成的目標，特別是一些文本修復任務入手。

Q3: 我想問的是做爲一個 PMC 成員，我想要參加更多的社區，我須要以怎樣的方式開始？
Craig Russell：其實在 Apache 裏，不少人是對多個項目進行貢獻的。作貢獻的方式有不少形式，若是你對一個項目有興趣，你能夠去讀讀他們的文檔，而後腦子裏就會產生問題，那麼問問題也就是你貢獻社區的的一種形式。由於你問這個問題，意味着確定有一些內容不太清楚、不太清晰。
你問出這個問題，就會促進社區去改善。或者你找到一個 BUG，哪怕他只是一個拼寫的錯誤，你只須要在寫郵件或者在相關的郵件後面跟帖，你就作了貢獻。若是後面你看見其餘人也在提這個問題，把你所知道的告訴他，也是貢獻的方法。貢獻不只僅是寫代碼。

Q4：怎麼樣去評估微服務自動化拆分工具的拆分質量？
A：拆分質量的衡量指標不少，更多的時候是主觀的感覺，難以量化。好比：對於注重交付速度的團隊，會盡量的將服務拆分得小；對於注重組織架構的團隊，會以下降業務複雜度，使團隊配合、交流以及技術演進更加方便，這時候可能就要拆的更小；而對於注重性能的團隊，若是服務拆過小，可能會帶去資源佔用變高、調用鏈路增加、響應時間增長的狀況。

Q5：剛提到 ServiceComb 提供了一個叫 Mesher 的項目，請問它是和 Istio 同樣的解決方案麼？以前你們對 Istio 的性能有詬病，不知道 ServiceComb-Mesher 有作這方面的優化麼？想在是否能夠用於商用階段？
A：ServiceComb-Mesher 與 Istio 不是一個對等的東西，你能夠理解爲 Mesher 是服務網格 Sidecar 的一種實現，只是在裏面作了一些治理能力的擴充。對於 Mesher 最主要是它是一個微服務多語言支持的解決方案，它不綁定運行環境，K8S、裸機均可以使用。ServiceComb-Mesher 是先商用後開源，具有商用要求。

Q6：剛提到的微服務改造工具能夠幫助用戶將普通應用裝換爲基於 ServiceComb 的微服務，並造成一些 API 文檔。我想問的是轉換後的工程是直接可運行的麼？轉換後須要人工介入修改代碼嗎？工做量有多少？語言的親和性怎麼樣？能不能稍微講解一下？
A：能夠理解 ServiceComb-Toolkit 生成的是一個微服務腳手架工程，目前還不支持將業務代碼一併遷移，但生成的微服務工程是能夠直接運行的。它已經作好的項目的基本配置，pom、java 包依賴、框架代碼等，用戶須要作的就是基於通信接口遷移具體的業務實現。對於業務代碼的遷移，實際上是有一些想法的，好比說能夠引入 AST 抽象語法樹對業務代碼進行分析。固然也歡迎你們一塊兒來提意見，一塊兒參與進來，一塊兒來完成這些想法。

在此感謝姜寧、王啓軍提供部份內容素材。

本文轉載至infoq

原文連接：https://www.infoq.cn/article/dbMDURNo0BCyh8Ivxxcb