Spring Boot 與微服務從0到1的實踐

轉自：花椒技術

Java微服務初探

微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表着一個小的業務能力。
微服務的概念源於2014年3月Martin Fowler所寫的一篇文章“Microservices”(http://martinfowler.com/articles/microservices.html)。

一、現狀與選擇

現狀

花椒的服務，無論是和前端靠的比較近的：比如H5官網；還是app服務：比如用戶，直播，經濟系統，雲控等服務，都是使用PHP開發的。選擇PHP的原因如下：

PHP的開發效率高。無需編譯，開發調試速度快。
團隊在PHP方面積累的經驗豐富：

成熟的輕量級框架：Web框架QFrame，數據庫QFrameDB，服務內部調用SDK：PepperClient，異步消息隊列SDK：ProcessClient等
豐富的LNMP調優經驗。
成熟的持續集成：發佈系統。

HULK團隊提供穩定高效的私有云解決方案：基於LNMP架構下的 Web服務管理：機器管理，Nginx等配置管理，Mysql，Redis等存儲服務。
工作中碰到的技術問題：
服務治理代碼和業務代碼耦合度高，不通用。使用 nginx + lua + 降級代碼。降級代碼寫到業務代碼中，新增降級需要新寫代碼，沒有一套通用降級，治理方案，耦合度高，影響業務穩定性。
團隊維護成本高。服務是分模塊的，大家各自維護各自的服務，底層沒有核心模塊，不同服務之間充斥着重複代碼，各自爲戰，複用性不足。舉例：錯誤碼很多服務是重疊的。
服務升級的技術成本很大。舉例：經濟系統虛擬貨幣服務分庫提升支付能力，因沒有成熟的組件，需要人肉手寫分庫代碼，更需要長時間的迴歸測試，壓力測試才能上線。
服務擴容速度慢，需要申請資源，部署，測試，上線。
服務優化，提升單機性能受限框架上限。受限於LNMP每個請求獨享一個進行，同步IO的機制而變得艱難，可以選擇更換框架爲swoole，選擇異步Redis的庫，這都需要大量的基礎調研，測試，業務代碼會被改的面目全非，項目週期會冗長。
整個後端的微服務做到了分拆：用戶，直播，消息，經濟系統，雲控等，項目的開發效率高，但是維護的工作對工程師得能力要求極高，治理，服務擴容，縮容，技術升級等問題還是困難重重，步履維艱。而java體系的spring cloud在服務註冊發現、熔斷限流、服務網關、分佈式配置等一道解決，而不是在php方案上自己找開源去拼湊重構，這方面java更成熟和成體系，而且java體系在新興的微服務架構Service Mesh中融合更好。

現有微服務解決方案

阿里

阿里使用java做爲主要開發語言，開源出框架也很多，分佈式和微服務框架：Dubbo、 Spring Cloud Alibaba 這兩個框架。Dubbo曾經一度停止維護，後來重新維護並開源到apache，Dubbo只能稱爲服務治理框架但距離系統完善微服務體系還有很多不足；Spring Cloud Alibaba 是基於Spring Cloud開源的一套微服務一站式解決方案，目前是一個孵化項目，它的倉庫也位於Spring Cloud孵化器中，很具有發展潛力。

項目地址 dubbo：https://dubbo.apache.org 、spring-cloud-alibaba：https://github.com/alibaba/spring-cloud-alibaba

騰訊

騰訊開源微服務框架：Tars 是騰訊從2008年到今天一直在使用的後臺邏輯層的統一應用框架，它集可擴展協議編解碼、高性能RPC通信框架、路由與發現、發佈監控、日誌統計、配置管理等於一體，但社區的活躍度不怎麼高，文檔也不夠完善。

項目地址：https://github.com/TarsCloud/Tars

華爲

華爲的ServiceComb框架: HWCloud在2017年6月發佈開源的一款微服務框架，集服務註冊、發現、通信和微服務治理能力爲一體，並默認提供集中化配置，目前已開源到apache，值得關注。

項目地址：https://servicecomb.apache.org

spring

不用說，寫過java的人都認識，spring自2003年開源至今，強大的生命力不斷更新迭代，java框架活躍度No1，基本一統web開發天下，springboot推出後更加贏得廣大java開發者青睞，隨後推出的springcloud微服務整套體系，spring經過十多年的發展已非常成熟，生態也比較完善。

選擇

選擇springboot2作爲微服務第一步基礎，原因如下：

成熟穩定，社區熱度極高，相關資料很多，問題方便解決。
極大地提高了開發效率：
使用註解、約定優於配置原則，大大減少了springBean的配置文件；
方便部署，項目可獨立打成jar包，無需依賴web容器；
與微服務相關框架方便集成，幾個註解搞定註冊中心、配置中心等集成；
提供運行時的應用監控，actuator監控健康；
方便集成第三方http、grpc組件，跨語言與php和go項目交互；

orm框架選擇：

選擇mybatis，相對於hibernate更輕便靈活，相對springjdbcTemplate功能更強大，使用 mybatis-generator 可以根據表反向生成model，提升開發效率

web容器選擇：

選擇undertow，
1、undertow在高負載情況下性能和穩定性要明顯優於tomcat；
2、比tomcat更輕便；

開發規範：

選擇安裝阿里開源的代碼規約掃描插件：Alibaba Java Coding Guidelines，能規範大家代碼風格，檢測潛在的異常，提前發現問題。

最終初步搭配：
springboot2 + mybatis undertow作爲web容器打入jar包中

二、穩步改進

要既保證支持現有業務的推進，又得保證系統穩定，以活動項目作爲先鋒，先趟一遍坑。

活動項目結構如下：

activity-java 活動業務包
activity-core 活動核心包
common-core 公共包
pepper-client 花椒client包
pepper-statistics 花椒統計監控包
pepperbus-client 花椒消息總線client包

迭代後的現狀架構圖

優化與改進：

改進

1.持續集成發佈由jenkins改爲gitlab
使用gitlab優點：

集成Code Review插件，方便代碼審覈；
CI/CD自動發佈部署，項目.gitlab-ci.yml文件配置好後，當開發分支合併到測試分支，自動編譯打包、運行測試用例、部署到測試環境，正式環境發佈、回滾也是輕鬆在web界面點擊幾個按鈕完成；
集成Kubernetes

2.註冊發現服務，選擇eureka/Nacos，
CAP理論指出，一個分佈式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由於分區容錯性在是分佈式系統中必須要保證的，因此我們只能在A和C之間進行權衡，在此Zookeeper保證的是CP, 而Eureka則是AP，當然後起之秀阿里開源的Nacos，也值得研究考慮。

3.其它

使用openfeign作爲成爲一個輕量級REST API客戶端，很方便訪問其它http接口，加個配置Hystrix和一個熔斷實現類就可以實現熔斷；
使用slf4j的MDC生成traceId爲了未來構建全鏈路監控做基礎；
基於註解+springEl+redis實現防併發、冪等性等；

三、展望未來

計劃中部署如下微服務組件：

對外gateway網關。
註冊中心euerka。
配置中心。
日誌服務。
服務治理中心。
wayne+k8s 容器化。

流程圖__1_

Service Mesh（服務網格）：下一代微服務？

什麼是Service Mesh？

服務網格（Service Mesh）是致力於解決服務間通訊的基礎設施層。它負責在現代雲原生應用程序的複雜服務拓撲來可靠地傳遞請求。實際上，Service Mesh通常是通過一組輕量級網絡代理（Sidecar proxy），與應用程序代碼部署在一起來實現，而無需感知應用程序本身。

爲什麼需要Service Mesh？

有了springcloud整套微服務架構，爲什麼我們還需要Service Mesh？經過上面的介紹不難發現，整個微服務要關注的組件太多了，在從單體應用程序向分佈式微服務架構的轉型過程中，開發人員和運維人員面臨諸多挑戰，而且隨着規模和複雜性的增長，服務越來越難以理解和管理。如果用TCP協議類比就很恰當，在TCP協議未出來之前，開發人員需要自己考慮服務間數據包的傳輸、粘包、網絡異常重試等問題，網絡傳輸代碼與業務代碼耦合，而TCP協議出來後，開發者不用關心網絡傳輸具體實現，有更多精力實現自己的業務，網絡傳輸TCP協議就對應服務網格的Sidecar模式，Sidecar模塊代理所有非業務功能。

Service Mesh 有如下幾個特點：