[[429339]]

01 微服務(wù)架構(gòu)簡介

微服務(wù)這個概念并不是近年才有的，但這兩年隨著以容器為核心的新一代應(yīng)用承載平臺的崛起，微服務(wù)煥發(fā)了新的生命力。

傳統(tǒng)的巨大單體(Monolithic)應(yīng)用程序在部署和運行時，需要單臺服務(wù)器具有大量內(nèi)存和其他資源。巨大的單體應(yīng)用必須通過在多個服務(wù)器上復(fù)制整個應(yīng)用程序來實現(xiàn)橫向擴(kuò)展，因此其擴(kuò)展能力極差;此外，這些應(yīng)用程序往往更復(fù)雜，各個功能組件緊耦合，使得維護(hù)和更新更加困難。

在這種情況下，想單獨升級應(yīng)用的一個功能組件，就會有“牽一發(fā)而動全身”的困擾。

在微服務(wù)架構(gòu)中，傳統(tǒng)的巨大單體應(yīng)用被拆分為小型模塊化的服務(wù)，每項服務(wù)都圍繞特定的業(yè)務(wù)領(lǐng)域構(gòu)建，不同微服務(wù)可以用不同的編程語言編寫，甚至可以使用完全不同的工具進(jìn)行管理和部署。

與單體應(yīng)用程序相比，微服務(wù)組織更好、更小、更松耦合，并且是獨立開發(fā)、測試和部署的。由于微服務(wù)可以獨立發(fā)布，因此修復(fù)錯誤或添加新功能所需的時間要短得多，并且可以更有效地將更改部署到生產(chǎn)中。此外，由于微服務(wù)很小且無狀態(tài)，因此更容易擴(kuò)展。

總體而言，微服務(wù)通常具有以下特點：

• 以單個業(yè)務(wù)或域為模型。
• 每個微服務(wù)實現(xiàn)自己的業(yè)務(wù)邏輯，包含獨立的持久數(shù)據(jù)存儲。
• 每個微服務(wù)有一個單獨發(fā)布的API。
• 每個微服務(wù)能夠獨立運行。
• 每個微服務(wù)獨立于其他服務(wù)且松耦合。
• 每個微服務(wù)可以獨立地升級、回滾、擴(kuò)容、縮容。

02 微服務(wù)架構(gòu)的主要類型

目前在微服務(wù)架構(gòu)領(lǐng)域有多種微服務(wù)治理框架，如Spring Cloud、Istio等。這幾種微服務(wù)架構(gòu)都符合上一節(jié)介紹的微服務(wù)架構(gòu)的特點，但實現(xiàn)的方式不同：有的通過代碼侵入的方式實現(xiàn)，有的通過使用代理的方式實現(xiàn)。

在Kubernetes出現(xiàn)和普及之前，實現(xiàn)微服務(wù)架構(gòu)需要通過像Spring Cloud這種代碼侵入的方式實現(xiàn)，也就是說，在應(yīng)用的源代碼中引用微服務(wù)架構(gòu)的治理組件。

在Kubernetes出現(xiàn)以后，我們可以將容器化應(yīng)用之間的路由、安全等工作交由Kubernetes實現(xiàn)，也就是說，應(yīng)用開發(fā)人員再也不必在開發(fā)階段考慮微服務(wù)之間的調(diào)用關(guān)系，只需關(guān)注應(yīng)用代碼的功能實現(xiàn)即可。這種無代碼侵入的微服務(wù)架構(gòu)(如Istio)越來越受到業(yè)內(nèi)和客戶青睞。

03 企業(yè)實施微服務(wù)架構(gòu)的收益和原則

從技術(shù)角度而言，企業(yè)實施微服務(wù)大致有以下幾個方面收益：

• 應(yīng)用更快部署：微服務(wù)比傳統(tǒng)的單體應(yīng)用小得多。較小的服務(wù)可以縮短修復(fù)錯誤所需的時間。微服務(wù)是獨立發(fā)布的，這意味著可以快速添加、測試和發(fā)布新功能。
• 應(yīng)用快速開發(fā)：微服務(wù)由小團(tuán)隊開發(fā)和維護(hù)，每個小團(tuán)隊最大規(guī)模為10人，合理的團(tuán)隊規(guī)模是5～7名成員，也就是“雙比薩團(tuán)隊”(亞馬遜在2012年提出這個概念，意思是5～7人吃兩個比薩剛好吃飽)。
• 降低應(yīng)用代碼復(fù)雜度：由于微服務(wù)比巨大的單體應(yīng)用小得多，因此，這意味著每個微服務(wù)的代碼量是可控的，這讓代碼修改變得很容易。
• 應(yīng)用易于擴(kuò)展：微服務(wù)通常是獨立部署的。各個服務(wù)可以根據(jù)服務(wù)接收的負(fù)載量靈活地擴(kuò)容和縮容。系統(tǒng)可以將更多的計算、存儲、網(wǎng)絡(luò)資源分配給接收高流量的服務(wù)，實現(xiàn)資源上的按需分配。

雖然微服務(wù)優(yōu)勢明顯，但為了保證微服務(wù)在企業(yè)內(nèi)順利實施，通常會遵循一些原則和最佳實踐：

• IT團(tuán)隊重組為DevOps團(tuán)隊：由微服務(wù)團(tuán)隊負(fù)責(zé)從開發(fā)到運營的整個生命周期管理。DevOps團(tuán)隊可以按照自己的節(jié)奏管理組員和產(chǎn)品，控制自己的節(jié)奏。
• 將服務(wù)打包為容器：通過將應(yīng)用打包成容器，可以形成標(biāo)準(zhǔn)交付物，大幅提升效率。
• 使用彈性基礎(chǔ)架構(gòu)：將微服務(wù)部署到PaaS上而非傳統(tǒng)的虛擬機(jī)，例如OpenShift集群。
• 持續(xù)集成和交付流水線：通過流水線打通從開發(fā)到運維的整個流程，這有助于微服務(wù)的落地。

在了解了微服務(wù)對于企業(yè)數(shù)字化轉(zhuǎn)型的意義后，接下來看一看PaaS、DevOps和微服務(wù)之間的關(guān)系。

04 PaaS、DevOps與微服務(wù)的關(guān)系

PaaS、DevOps、微服務(wù)的概念很早就出現(xiàn)了。廣義上的微服務(wù)和DevOps的建設(shè)包含人、流程、工具等多方面內(nèi)容。IT廠商提供的微服務(wù)和DevOps主要是指工具層面的落地和流程咨詢。

在Kubernetes和容器普及之前，我們通過虛擬機(jī)也可以實現(xiàn)微服務(wù)和DevOps(CI/CD)，只是速度相對較慢，因此普及性不高(想象一下通過x86虛擬化來實現(xiàn)中間件集群彈性伸縮的效率)。而正是容器的出現(xiàn)，為PaaS和DevOps工具層面的落地提供了非常好的承載平臺，使得這兩年容器云平臺風(fēng)生水起。

這就好比4G(2014年出現(xiàn))和微信(2011年出現(xiàn))之間的關(guān)系。在3G時代，流量費較貴，大家對于微信語音和視頻聊天不會太感興趣;到了4G時代，網(wǎng)速提高而且收費大幅下降，像微信這樣的社交和互聯(lián)網(wǎng)支付工具才能興起和流行。

容器引擎使容器具備了較好的可操作性和可移植性，Kubernetes使容器具備企業(yè)級使用的條件。而IT界優(yōu)秀的企業(yè)級容器云平臺——OpenShift又成為DevOps和微服務(wù)落地的新一代平臺。

OpenShift以容器技術(shù)和Kubernetes為基礎(chǔ)，在此之上擴(kuò)展提供了軟件定義網(wǎng)絡(luò)、軟件定義存儲、權(quán)限管理、企業(yè)級鏡像倉庫、統(tǒng)一入口路由、持續(xù)集成流程(S2I/Jenkins)、統(tǒng)一管理控制臺、監(jiān)控日志等功能，形成覆蓋整個軟件生命周期的解決方案。

所以說，OpenShift本身提供開箱即用的PaaS功能，還可以幫助客戶快速實現(xiàn)微服務(wù)和DevOps，并且提供對應(yīng)的企業(yè)級服務(wù)支持。

關(guān)于作者：魏新宇，紅帽副首席解決方案架構(gòu)師。在IaaS、PaaS方面有豐富的經(jīng)驗，致力于開源解決方案在企業(yè)中的推廣和應(yīng)用。從售前角度主導(dǎo)了紅帽在金融、汽車行業(yè)的多個PaaS項目。曾就職于華為、IBM、VMware。

郭躍軍，目前就職于VMware，擔(dān)任Solutions Engineer。曾于紅帽擔(dān)任PaaS咨詢顧問、AWS顧問服務(wù)團(tuán)隊擔(dān)任云架構(gòu)咨詢顧問，熟悉私有云和公有云生態(tài)。從2015年接觸容器技術(shù)開始，一直奮戰(zhàn)在PaaS建設(shè)一線，參與了很多OpenShift項目的競標(biāo)、PoC、咨詢和落地實施，幫助很多企業(yè)實現(xiàn)了數(shù)字化轉(zhuǎn)型。

本文摘編自《OpenShift在企業(yè)中的實踐：PaaS DevOps 微服務(wù)》(第2版)，經(jīng)出版方授權(quán)發(fā)布。