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 有如下幾個特點：
- 應用程序間通訊的中間層
- 輕量級網絡代理
- 應用程序無感知
- 解耦應用程序的重試/超時、監控、追蹤和服務發現
細節圖：
鳥瞰圖：
Service Mesh相關框架：第一代以Linkerd和Envoy為代表 ；第二代以Istio和Conduit為代表。
閱讀更多 微軟NETCORE 的文章
