【51CTO.com原創稿件】2018年5月18-19日，由51CTO主辦的全球軟件與運維技術峰會在北京召開。來自全球企業的技術精英匯聚北京，暢談軟件技術前沿，共同探索運維技術的新邊界。而在本次大會上，除了眾星云集的主論壇環節，12場分論壇更是各具特色，分別聚焦了時下最受關注的容器、AI、區塊鏈、大數據、物聯網等技術領域。

　　在19日下午的“微服務架構設計”分論壇現場，阿里巴巴技術專家徐冬晨擔任本場論壇的出品人，她與58到家CTO沈劍、餓了么計算力交付部負責人李健、百度云資深研發工程師何方石分別給場內聽眾帶來了四場精彩演講，分享了微服務架構在落地過程的一些可行方案及實踐思路。

　　58到家沈劍：58速運微服務架構解耦***實踐

　　沈劍首先分享了58速運在業務開展過程中遇到的運維問題。據他透露，隨著58同城業務持續的發展，數據量也隨之慢慢提升。他們很快就遭遇了一個很有代表性的挑戰——代碼拷貝導致業務痛點。由于業務是逐漸增長的，在這個過程中，不同技術團隊會有重復功能的需求，為了快速上線，不同技術團隊之間拷貝相同代碼，并在此基礎上借鑒修改。這樣帶來的弊端就是，一旦原來的那套代碼出現問題，其他所有拷貝的地方，全部都需要修改，因為這些拷貝的代碼產生了跨系統、跨業務的耦合。

　　不僅如此，被迫聯動升級也曾困擾過他們。由于數據量增多，訪問量也隨之增加，系統中的各個子系統時不時會出現問題，例如吞吐量過大、新增業務場景帶來數據庫讀寫壓力、數據讀取流程改變等等。漸漸地，底層復雜性不斷擴散到上游業務層，導致業務層也需要配合修改。

　　***沈劍和技術團隊決定用微服務來化解這些困境。微服務化之后，所有業務側都通過RPC像調取本地函數一樣去調取遠端的數據，至于這個數據是存在哪個數據庫里，還是緩存里，都不需要關注，他們只需要關注服務層，當底層有升級的時候，所有業務線都不需要變動，只有服務需要升級。通過服務化，他們徹底解決了底層復雜性的耦合問題。

　　沈劍還給微服務架構設定了兩條原則，***條原則是數據庫私有，任何上游不得繞過服務層去訪問底層數據庫，業務部門只能調用接口，通過接口去訪問。第二條原則是對上游提供有限且通用的接口，并且服務層要保證***的性能，確保可以解決業務部門關于吞吐量、訪問量的問題。不過如此一來，服務層就會變得非常重要，沈劍建議將公司最基礎的微服務化放在架構部，或者專門成立一個部門，由比較資深的技術人員負責維護。

　　改造之后，他們很快就享受到微服務帶來的好處，例如加強復用性，消除代碼拷貝耦合，屏蔽復雜性，消除復雜性耦合，而且還保證了SQL質量，可以給業務部門提供有限服務，***性能。同時確保系統擴展性，消除數據庫實例耦合。更重要的，調用數據更方便了。

　　但是微服務是一把雙刃劍，有優勢也同樣有弊端。沈劍分享道，微服務也導致了系統復雜性上升，讓層次間依賴關系變得復雜。與此同時，運維和部署更麻煩，雖然目前58速運計劃在未來開發自動化的運維腳本和運維平臺，但如果是小型的研發團隊，微服務帶來的運維壓力可能會非常大。系統監控和問題定位也遇到同樣的問題，變得非常復雜。“微服務，不是簡單引入一個RPC框架，它需要一系列基礎設施的支撐。” 沈劍總結道。

　　阿里巴巴徐冬晨：JVM- sandbox_穩定性體系的構建

　　徐冬晨認為，隨著軟件部署規模的擴大，系統功能的細化，系統間耦合度和鏈路復雜度不斷加強。要繼續保持現有規模系統的穩定性，需要實現并完善監控體系、故障定位分析、流量錄制回放、強弱依賴檢測、故障演練等支撐工具平臺。出于對服務器規模和業務穩定性的考量，這些配套工具平臺需要具備三個特點，即無侵入、實時生效、動態可插拔。

　　要實現這些，多少都會觸及到底層技術——動態字節碼增強。如果每個工具都自己實現一套字節碼增強邏輯，前期實現的門檻與后期維護成本高，且不同工具間相互影響造成不可預知的風險。如何降低門檻屏蔽風險[鳶瑋1] ，降低研發運維成本，同時又能支持上層多個工具平臺功能的快速實現和動態管理，成為阿里集團的目標。在這樣的背景下，JVM-Sandbox 誕生了，這是一套實時無侵入的字節碼增強框架，它可以提供動態增強類指定的類，獲取人們想要方法的參數、返回值和行信息;提供動態可插拔容器。

　　JVM—Sandbox能處理哪些問題呢?徐冬晨表示，它可以提供線上故障定位、線上系統流量控制、線上故障模擬、性能壓測、錄制回放、鏈路跟蹤六大服務。徐冬晨列舉了阿里集團內部的三個應用場景，一是線上故障演練，他們僅用1周時間就完成了故障注入部分的重構，在掛載效率和成功率方面有了明顯的提升，縮短了演練的時間;二是依賴檢測，利用JVM-Sandbox的模塊容器的特性，阿里技術團隊將前人開發的模塊與新增模塊一起掛載共同工作，完成依賴檢測、故障注入等操作;三是錄制隔離回放機制，即利用JVM-Sandbox的開發錄制模塊，和回放模塊，實現線上錄制線下回放，提高回歸效率，拓展測試范圍。

　　據徐冬晨介紹，JVM-Sandbox基于JVMTI技術規范，為觀察和改變代碼運行結果提供了即插即用模塊接口的容器。而且還為AOP提供了一個新的實現方案——以插樁代替代理。“在工作中需要使用字節碼增強技術，進行工具開發、實現業務功能的開發、測試的同學會非常需要它。”

　　餓了么李健：基于容器的混合云實踐

　　李健介紹到，管理系統常見的一個場景就是混合云的管理，在餓了么業務快速增長過程中，資源規模增長也非常迅速，這也導致了服務器類型繁多，交付需求多樣。為了滿足業務的需求，讓應用交付更為靈活穩定，餓了么想到了一個新思路，把物理資源抽象，對計算力進行標準化設置，統一對開發人員輸出。如此一來，可以極大減少交付成本，而且標準化之后可以管理更多IT基礎設備。

　　在經過仔細技術對比之后，餓了么選擇了構建eleme[鳶瑋2] 容器平臺來實現應用交付。具體說來，eleme容器平臺會交付三部分內容，一是客戶應用部署，這個最常見，業務把應用交給開發部門，開發部門負責讓應用實現，提供應用服務;二是標準服務一鍵交付，由于業務部門有很多團隊，每個團隊可能需要一套獨有的環境來實現服務，但每個服務之間又需要建立聯系，并且具有可復制性，這就要求技術團隊必須提供標準服務，避免搭建復雜的運維環境。三是服務器的交付，即對外輸出計算力。

　　構建容器平臺離不開技術選型，李健認為，目前無論從生態還是活躍度來看Kubernetes(Google開源的容器集群管理系統)都已成為容器編排事實上的標準。“雖然企業在容器化時遇到的問題不可能完全一樣，技術選型時可以根據實際情況選擇，但脫離了標準往往意味著成本的大幅上升。”除了標準之外，李健建議技術選型還需要去重點考慮與自身業務的契合度、擴展性、生態發展、前瞻性。

　　那么Kubernetes落地戶還會遇到哪些阻礙呢?李健透露，首先是容易遇到Pod(一個Kubernetes抽象，表示一組一個或多個應用程序容器以及這些容器的一些共享資源)重啟方式的問題，因為Pod重啟意味著新建一個Pod，之前版本就不再使用了，很多企業環境是無法接受這個設定的。

　　另外一個問題是Kubernetes無法限制容器系統大小，一旦有企業混合業務時，容量高達100G以上，系統會立刻報警提示磁盤已滿。這就需要企業另行開發修改。

　　***一個問題是DNS(域名系統)改造。很多企業都有自己的域名區域，并且希望能夠集成到 Kubernetes DNS 的命名空間去，例如混合云用戶可能希望能在集群內解析他們內部的 “.corp”，這就需要企業進行DNS改造。

　　百度云何方石：揭秘百度云函數計算實現細節

　　何方石在現場向大家揭秘了他和技術團隊在百度云如何實現函數計算這個產品。函數計算實際上是一種無服務器的計算交付的產品，不需要引入任何框架，用戶只需要在百度云的控制平臺上或者通過API去編寫自己的函數。函數編寫完之后，百度云可以通過云端試點的觸發器，或者API的調用來執行用戶這段函數的業務邏輯。

　　那么人們可以利用函數計算實現哪些功能呢?一是無服務器后端，搭配HTTP觸發器或API Gateway產品可以快速實現后端API，并無需考慮配置服務器與運維;二是實時數據流處理，從消息隊列批量消費流數據，聚合、整理數據并生成指標，可以自動根據負載消費數據;三是IoT后端，與IoT Hub聯動實現對IoT設備的管理能力，服務可自動調整規模，應對IoT設備增長;四是Cloud Native Connector(云原生)，基于event-driven(事件驅動架構)的云原生時代，云服務通過事件+函數計算互相打通，形成生態，更加靈活。

　　演講***，何方石將函數計算的特點歸納為“高彈性、低成本、輕量級、低延遲”。具體來看，首先它是一個高彈性的服務，其次它具有比較低的開發成本，再者由于云平臺運行的是單一計算的函數，所以它具備輕量級的特色，***是低延遲特點，一秒鐘一次調用和一秒鐘一萬次調用的頻率對比，延遲時間非常接近。

　　以上內容是51CTO記者根據WOT2018全球軟件與運維技術峰會的《微服務架構設計》分論壇演講內容整理，更多關于WOT的內容請關注51cto.com。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】