微服務架構被認為是構建大型復雜系統(tǒng)的最佳理論指導，其采用了分而治之、單一職責、關注點分離等方法論來設計系統(tǒng)架構。微服務的實現(xiàn)方式和思路有很多種，本文簡述基于kubernetes的微服務平臺建設思路及技術選型。

應用架構發(fā)展歷史

要了解微服務架構提出的背景，首先我們來看一下應用架構的發(fā)展歷程，如下圖所示：

application.png

• 單體應用：傳統(tǒng)應用的開發(fā)技術為.NET、J2EE等技術，開發(fā)完成后部署在websphere、weblogic這樣的商業(yè)容器中（或者開源的tomcat）。應用間的交互一般通過CORBA、DCOM這樣RPC風格的組件進行，此時并沒有服務化的概念。部署的環(huán)境一般為小型機、服務器。
• SOA架構：業(yè)界在意識到了系統(tǒng)集成標準化的重要性后，提出了SOA的理念。SOA強調的是服務化、標準化，通過制定統(tǒng)一的應用接口標準，所有的應用都可以方便的提供服務，并且也可以快速調用其他應用提供的服務，通過一個集中化的服務中間件，系統(tǒng)集成的效率大大提高。經典的落地場景就是ESB企業(yè)服務總線。交互協(xié)議多用基于SOAP的web service。在這個時期，出現(xiàn)了虛擬化技術，應用可以部署在vmware虛擬機中，大大提高了資源的利用效率。
• 微服務：其實在martin fowler寫那篇經典的微服務論述文章前，業(yè)界很多公司早就在實踐微服務了。國外的有netflix oss技術棧，國內的有大名鼎鼎的dubbo框架。esb在落地過程中碰到了很多問題，集中化的中心節(jié)點很容易造成性能瓶頸，并可能產生單點故障，在互聯(lián)網公司的實踐中上千甚至上萬的服務，已經不可能通過esb去承載。微服務與傳統(tǒng)的esb區(qū)別就是去中心化，去掉了中心esb節(jié)點，取而代之的是一個分布式的服務化框架，提供服務注冊、服務發(fā)現(xiàn)、限流熔斷、配置管理等一系列高級功能。由于互聯(lián)網的流行，此時的交互協(xié)議多為輕量級的RESTful風格協(xié)議。這個時期，是云計算真正落地的時期，以aws為代表的Iaas技術大行其道，從根本上改變了應用部署的方式。（事實上，netflix就是基于亞馬遜的EC2彈性節(jié)點來動態(tài)的增加、減少微服務實例的，應用架構的靈活性大大增加）
• 云原生：云原生其實就是微服務的一種落地，但我認為，云原生已經可以看作是下一代的應用架構了。它從平臺層面重新審視整個微服務實施中的關注點，并且以宏觀視角給出了完整的解決方案，強調與devops的整合，整體抽象層次最高，且做到了語言無關，這是上一代微服務所做不到的。需要注意的是，在云原生時代，應用和基礎架構需要進行深度集成，換句話說，只有你在kubernetes這樣的云基礎設施上部署的應用，才可以算成是“云原生”應用。應用充分利用了基礎架構的能力（微服務能力），這才是“云原生”的真諦（天生被設計需要跑在云上的應用）。

云原生概念的提出可謂是業(yè)界對軟件工程長期發(fā)展的一個高度總結和最佳實踐集合，以下是紅帽公司對于云原生概念的解釋，個人是比較認可的

cloud-native.png

微服務解決方案

提到微服務，就不得不提到Spring Cloud和Kubernetes（太早的dubbo就忽略了），這兩者社區(qū)都非?；钴S，都有完整的微服務解決方案，有大量的落地案例。但他們解決問題的思路和方式完全不同，這也決定了兩者未來的發(fā)展方向。這邊進行一個全方位的對比，對比完之后你就知道，為什么kubernentes被稱之為下一代的基礎應用架構。

微服務公共關注點

首先我們來看下，紅帽公司總結的所謂的微服務公共關注點。可以說，不管你用哪種方式、哪個平臺去實現(xiàn)微服務，這些內容都是你必須要去關注并實現(xiàn)的。

微服務平臺.png

可以看到，里面差不多一半關注點是和運維相關的。這么看來，似乎拿spring cloud和kubernetes比較有點不公平，spring cloud只是一個開發(fā)框架，對于應用如何部署和調度是無能為力的，而kubernetes是一個運維平臺。也許用spring cloud+cloud foundry去和kubernetes比較才更加合理，但需要注意的是，即使加入了cloud foundry的paas能力，spring cloud仍然是“侵入式”的且語言相關，而kubernetes是“非侵入式”的且語言無關。

功能對比

先來看下這張圖

image.png

可以說，spring cloud關注的功能是kubernetes的一個子集，下面來詳細對比一下：

可以看出，兩邊的解決方案都是比較完整的。kubernetes這邊，在Istio還沒出來以前，其實只能提供最基礎的服務注冊、服務發(fā)現(xiàn)能力（service只是一個4層的轉發(fā)代理），istio出來以后，具有了相對完整的微服務能力。而spring cloud這邊，除了發(fā)布、調度、自愈這些運維平臺的功能，其他的功能也支持的比較全面。相對而言，云廠商會更喜歡kubernetes的方案，原因就是三個字：非侵入。平臺能力與應用層的解耦，使得云廠商可以非常方便的升級、維護基礎設施而不需要去關心應用的情況，這也是我比較看好service mesh這類技術前景的原因。

談談Istio

關于Istio，其實已經討論的比較多了。作為近兩年微服務領域最熱門的話題，這里我不準備展開Istio的技術細節(jié)，感興趣的可以登陸servicemesher技術社區(qū)或者Istio官方網站查閱資料，這里只談談我個人的看法。根據官方網站的描述，Istio主要被設計用來連接、保護、控制、觀測服務，下面分別來講一下：

連接

主要是定義路由規(guī)則，配合virtual service和destination rule實現(xiàn)各種高級路由功能，能夠非常細粒度的實現(xiàn)灰度、金絲雀、多版本路由等能力，這塊是istio的最大亮點，spring cloud這部分能力完全缺失，沒得比。

保護

主要是端到端的mTLS加密、服務間認證授權、終端用戶認證授權，這部分Spring Cloud提供了Spring Cloud Security可以實現(xiàn)最終用戶認證功能，但Spring Security本質上來講是在單體應用的背景下設計出來的，運用在分布式系統(tǒng)上有諸多不便（例如Session同步），端到端加密和服務間認證也是沒有的。

控制

主要是策略（policy），例如黑白名單、限速等各類控制能力，通過適配器（Adapter）實現(xiàn)，并且可以自定義適配器擴展各類個性化的控制能力。這部分由于需要通過mixer來實現(xiàn)，歷來爭議很大（Istio最新版本policy功能都是默認關閉的）。Spring Cloud可以通過Hystrix/Resillience4j來實現(xiàn)限速、熔斷等方面的功能，理論上說istio的設計是更好的，因為適配器是可以靈活擴展的。可惜mixer的設計問題，現(xiàn)在處于比較尷尬的地位，mixer v2計劃把policy做到sidecar里面，大方向是對的，可以期待一下。

觀測

主要是遙測（telemetry）。一般我們說的可觀測性（Observability），包含Logging、Tracing、Metrics 這三部分，istio也都有解決方案。Logging和Metrics不說了，都是通過envoy收集好以后上報給基礎設施后端（也是通過mixer，不過這個是異步的，稍微好一點）。Tracing比較有意思，istio官方原來的宣傳是完全不需要修改代碼，即可實現(xiàn)分布式跟蹤，但其實還是需要修改一點代碼的（雖然不多）。經過我們張超盟大哥的反饋，istio官方修改了措辭，變成了只需要修改一點代碼。大家可以看下官方的介紹頁面https://istio.io/docs/tasks/telemetry/distributed-tracing/overview/，可以看到bookinfo這個示例里面，應用是做了header的上下文傳遞的工作的。這部分來說，雖然spring cloud也需要引入sleuth的jar包，但因為spring cloud本來就是一個侵入式框架，這部分反而感覺侵入性沒istio那么大（sleuth會自動注入到RestTemplate里面去埋點，業(yè)務代碼不需要改動）。當然如果追求真正的無侵入（spring cloud sleuth使用的基礎是你的應用要基于spring cloud框架進行開發(fā)），那么需要使用pinpoint或者skywalking這樣的基于字節(jié)碼注入的tracing框架。

結論

上面我詳細分析了目前主流的微服務框架spring cloud與kubernetes，并對各自的優(yōu)劣進行了對比。在目前這個時間節(jié)點，對于中小型的技術團隊來說，我推薦的組合就如文章標題所說：使用spring boot+kubernetes來實現(xiàn)微服務架構，這是一個比較清爽的搭配。如果是沒有歷史包袱的，且底層基礎設施準備上k8s的技術團隊來說，個人認為現(xiàn)在來說已經沒有必要使用spring cloud了。畢竟kubernetes已經提供了比較完整的微服務解決方案，何苦再自己搞一套服務注冊、服務發(fā)現(xiàn)、配置管理的輪子呢（況且還是語言綁定）？

當然選擇kubernetes，代價就是限流、容錯、安全、路由等能力的缺失，所以說究竟怎么選擇，還是取決于團隊與公司自身的實際需求。而對于istio來說，目前我不推薦上生產。service mesh總體來說還是處于一個非常早期的階段，但可以保持高度關注。由于service mesh自身無侵入的特性，未來在kubernetes上升級sidecar也是完全透明的，可以期待一下mixer v2出來以后的service mesh的技術走向。

基于spring boot+kubernetes的微服務架構技術選型如下：（僅代表個人觀點）

• 服務注冊與服務發(fā)現(xiàn)：kube-proxy+coredns
• 配置管理：ConfigMap
• api網關：Ingress（外部網關，位于集群入口，https加密，證書管理，域名管理，限速等）+zuul（內部網關，用于服務轉發(fā)，并可以開發(fā)比較靈活的各類定制化適配器）
• metrics監(jiān)控：prometheus+spring actuator
• 調用鏈監(jiān)控：skywalking
• 日志收集：EFK

參考資料

https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/