微服務進階之路 容器落地避坑指南

編者按：容器和容器編排系統僅僅是部署和運行的基礎平臺，開發人員須要關注更多的是部署在平臺上的應用。容器時代，應用架構發生了巨大變化，若是要讓應用在容器平臺上發揮其最大的功效，咱們就必須走上微服務道路。然而，容器落地的過程當中路多坑更多，微服務進階之路須要更多經驗之談。

——本文來自青雲QingCloud 應用及容器平臺研發總監周小四 、KubeSphere 容器平臺產品經理於爽。

微服務架構相對於單體架構有很大的變化，也產生了一些新的設計模式，好比 sidecar，如何開發一個微服務應用是一件有很大挑戰性的事情，咱們常常會聽到有人討論如何劃分微服務，多細的顆粒度纔是微服務等問題。初學者常常會處於一個「忐忑不安」的狀態，因此咱們急須要知道如何才能走上正確的微服務道路，或者須要一些最佳實踐指導咱們如何設計、開發一個微服務應用。

不驕不躁不跟風 知己知彼方可百戰不殆

雖然如今已經進入到一個不談微服務就落伍的時代，但做爲 IT 從業者，咱們必定要站在切身利益出發，多思考幾個「爲何」，不要急於跟風。緣由很簡單，無論外面如何風吹雨打，只要你的房子足夠結實、安全、舒服，那通常狀況下就不須要拆除重建，因此在決定繼續沿用單體架構仍是轉向微服務架構以前，咱們必定要作兩件事情：

第一件事，從外部瞭解兩種架構各自的優劣：

 能夠看到，單體應用並非一無可取。

 第二件事，審視咱們本身的業務：

• 上述單體架構列出的一些問題是否已經嚴重影響了咱們的業務？

  
  

• 企業新的業務系統是否要知足快速迭代、彈性等需求？

  
  

• 團隊內是否有 DevOps 氛圍？

  
  

• 企業內是否有足夠的動力和技術儲備去接觸新的技術？

瞭解了單體應用和微服務應用的優劣特色，分析了企業自身的業務訴求和實際狀況，最終仍是決定轉型微服務架構，那麼咱們也要清楚這不是一朝一夕的事情，須要分階段逐步推動。

矇眼狂奔不可取 按部就班方可順利進階

第一階段試煉—— 開發新應用

對於初次接觸微服務的企業，選擇新應用入手是正確的方式。

第一步能夠選擇 web-scale、無狀態類型的新應用上手，好比基於 nginx 的網站、文檔等，這類應用很是簡單且容易實現，並且能體驗到微服務在容器平臺上的各類功能。

有了必定的經驗以後，第二步就能夠開發有狀態類型的新應用，有狀態服務的最大挑戰就是數據管理。

敲重點，跟以往單體應用的共享數據庫不一樣，微服務應用中的每個服務「獨享」本身的數據庫，服務之間須要經過 API、事件或消息傳遞的方式來相互訪問對方的數據，而不是經過直接訪問對方數據庫的方式。

換句話說，理想中的微服務是封裝本身的數據，經過API暴露數據出去，從而避免數據耦合，這樣每一個微服務的數據格式發生變化也不影響其它微服務的數據調用。開發過和升級過大型企業單體應用的人對此會深有體會，一旦有人改變了數據庫 schema，整個應用都有可能啓動不起來，團隊開發效率會大大下降。

微服務架構並不盡善盡美，適合本身的方案纔是王道。

不難理解，微服務數據是犧牲強一致性而經過最終一致性的方式來管理，這對數據的劃分帶來很大難度，好比不能再用 join 的方式訪問不一樣服務之間的數據表，實際當中也比較難作到或者作起來很麻煩，如今也沒有成熟且好用的庫或框架提供微服務的數據管理，並且某些應用確實須要強一致性。

而此時，咱們不能通盤否認此類應用微服務化的可行性，應該適當折中或「妥協」，採用 miniservice。

Miniservice 在開發與部署的獨立性和敏捷性方面相似於微服務(microservice)，但沒有微服務那麼強的約束。一般狀況下，一個 miniservcie 能夠提供多個功能，這些功能之間能夠共享數據庫。這個時候千萬不要懼怕混合架構，不要懼怕本身的微服務應用是否「正統」，「think big，start small，move fast「纔是咱們應該遵循的哲學。

所以，一個企業應用裏既有 microservice 也有 miniservice，甚至有單體部分（能夠稱之爲 macroservice）都是能夠接受的。

以一個電商平臺舉例，在整個場景裏面，業務開發人員面對的主要壓力來自前端頻繁的變更，由於要應對頻繁的促銷、推廣、降價等活動，因此面對消費者最前端的業務須要快速迭代。消費者會不停的瀏覽商品，最終產生交易的請求數量要遠低於獲取商品信息的請求數量，所以將前端業務無狀態化，進行微服務拆分、解耦，即可以快速應對市場變化，靈活作出改變。

那是否是把整個平臺都作到微服務級別會變得更好？答案是「不肯定」，由於當微服務量級到達必定程度，由此產生的管理和運維壓力是指數級增加的。而實際上，對於有些業務來說也沒有必要微服務化，好比不少電商平臺都有 2B 的業務，其業務變化的頻度和壓力沒有 2C 那麼大，那以 macroservices 或者 miniservices 的方式去交付也是能夠的。

開發人員應該分析在整個應用架構體系中，哪些適合微服務化，哪些亟需微服務化。

實踐出真知

在上面的電商案例中，咱們提到了服務無狀態化，之因此指望服務無狀態化，是由於無狀態應用能夠作到快速的擴縮容，能夠應對井噴流量，能夠最大效率的利用計算資源。

咱們常常聽到，以無狀態爲榮，以有狀態爲恥，說的就是對於一個服務要儘可能無狀態化它，好比用戶 session 管理，之前咱們在業務邏輯模塊進行管理，致使這些模塊不能按照無狀態方式任意伸縮。咱們能夠把這些 session 的管理抽取出來放到一個高可用或分佈式的緩存中管理，業務模塊經過調用API的方式去獲取 session，這樣就實現了這些模塊的無狀態化。

但這並不意味着全部服務都作到無狀態纔是最好的，開發者要細細思考本身的業務模型並進行服務拆分，不要爲了無狀態而無狀態，由於老是會存在有狀態服務的。

第二階段進階—— 改造遺留應用

若是咱們通過認真思考後仍決定對遺留應用進行微服務化，好比須要新增功能、快速迭代現有功能等，那麼最好遵循一些最佳實踐經驗。顯然，另起爐竈開發一套新的系統不太現實，失敗的機率很是高。

第一點注意：新增功能點不能再在原有單體應用基礎上開發，而是須要按照微服務方式開發，但因爲這個微服務是隸屬於原來單體應用的一部分功能，因此一般狀況須要訪問單體應用的數據，這個時候須要經過API的方式訪問，以防止兩者之間發生緊耦合。對於單體部分來講，不管是採用 Facade，仍是 Adapter 或 Translator 模式提供 API，都是爲新增的微服務模塊提供鬆耦合的訪問方式。

第二點注意：對於已有的單體部分也能夠逐步微服務化，可選擇常常變化、須要快速迭代知足用戶需求的部分着手進行改造。通過幾輪改造後要麼總體替換掉原單體應用，要麼剩下的是穩定不變的單體部分，周圍就都是改造過的微服務混合架構了。

第三階段收放自如——Service Mesh

Service mesh 是微服務架構的一部分，它本質上是一個分佈式計算中間件，經過攔截流量和安置策略來管理和優化服務之間的通訊，使得服務變得更加健壯和安全。一般會提供微服務之間認證、鑑權、加密、服務發現、請求路由、負載均衡、服務自愈等功能。

部署微服務應用，service mesh 是必不可少的部分。這是由於微服務應用是一個分佈式的應用，所以相對於單體應用來講在穩定性、可管理性等方面都有很大難度，須要有 service mesh來管理幫助服務變得更加健壯和安全。

所以，Service mesh 選型也是比較重要的，常常聽到有人糾結是選擇 Istio 仍是 Spring Cloud 等。咱們認爲 Istio 是 service mesh 的發展方向，從架構來講，它解耦了控制平面和數據平面，使得開發者能夠專一於應用業務邏輯的開發，而複雜的分佈式應用服務之間的通訊交給 service mesh 來控制。

Spring Cloud 在架構設計理念上是落後的，試想一下，開發者在開發微服務的時候還要思考如何在代碼中實現熔斷、灰度發佈、負載均衡等問題，負擔是很是重的。

更重要的是 Spring Cloud 類型的 service mesh 只支持 Java 語言，徹底違背微服務能夠任選語言開發的主張，並且有 vendor lock-in 嫌疑。

Istio 身上鮮明的標籤不少：自然適合 Kubernetes 平臺，不侵入代碼，無語言綁定，但不得不認可，Istio 還在發展過程中，目前也有一些問題亟待解決：

• 性能依然不夠理想

基於 Istio 實現的微服務，因爲虛擬化、轉發等因素形成的性能損耗依然過大，不過積極的方面是咱們看到一方面這是社區持續改進的重點，另外一方面咱們看到你們在作一些有效的嘗試，好比經過 cilium 作 service mesh 的 proxy，提高性能；

• 門檻高

Istio 雖然控制面作的很優秀，但上手成本依然很高，不少企業用戶還處在容器化改造階段，以一種複雜面貌去呈現是很難很快融入企業 IT 架構中的；

• 落地實踐少

雖然社區火熱，被談論的熱度很高，但企業用戶或者在觀望，或者在嘗試，咱們能看到的是有技術實力的互聯網公司將 Istio 中的某個組件拆解出來，或改造、或接入他們現有微服務治理平臺，但這又會形成一種和社區主分支不一致的問題，爲未來可否和社區保持一致帶來些許擔憂，是否會走上廠商綁定的老路還須要觀察。

值得一提的是，在2018年上海 KubeCon 大會上，Google 的開發者講述了在美國三家公司成功將 Istio 用於生產的案例，相信相似的事情會發生的愈來愈多，也期待今年上海的 KubeCon 能看到更多來自 Istio 的分享。

雖然 Istio 存在上述問題，但咱們更應看到其社區正在飛速增加，就比如一兩年前 k8s、docker swarm 和 Mesos 之爭同樣，那個時候 k8s 強大的生態活躍度爲它最終勝利打下了良好的基礎，咱們認爲 Istio 就是在 service mesh 領域的 k8s，將來頗有可能會贏得這個領域的主導地位。

當一個應用的微服務愈來愈多的時候，service mesh 變得很是重要，並且目光看得更遠一些，隨着 FaaS 步入業務開發者的視野，你們愈來愈享受這種便捷、靈活的開發方式，這意味着以服務視角的開發模式會愈來愈流行，所以 service mesh 框架會變得愈來愈重要。

綜上所述，經過 Istio 構建微服務治理屏幕，學習曲線起點比較高，運維也很是麻煩，運維人員關注的是功能的輸出，好比熔斷、限流、灰度發佈等，但 Istio 要求他們先要部署組件，編輯 yaml，瞭解各類抽象的參數，這就比如在看 3D 電影前，讓觀衆本身先要組裝 3D 眼鏡同樣。

所以，微服務進階之路道阻且長，企業須要一個平臺級商業產品，能夠從業務視角來管理微服務的可視化工具或者平臺，下降用戶的學習和運維成本，提升用戶的業務價值輸出能力，幫助用戶重塑數字化時代核心競爭力。

-FIN-

「大道至簡 舉重若輕」，誠邀您參加將於 4 月 19 日在北京北辰洲際酒店舉辦的 KubeSphere 容器平臺產品發佈會，輕量級調度全棧雲功能，助力企業快速步入雲原生之旅，點擊閱讀原文掃碼便可報名，帶你在數字化轉型中一步領先！