點擊上方藍字關注“信息化時代”
一提到Microservice微服務，你首先會聯想到什麼？簡易的開發和部署，應用組件的獨立可擴展性，避免長期技術鎖定……這些都是微服務的優勢。以雲計算、互聯網+、移動應用等為代表的新興業務對IT運行效率、開發效率、業務模式創新等提出了更高的要求。有人說，傳統行業對IT效率的變革需求是微服務成長的土壤，微服務正在成為許多企業構建應用時的首選。
什麼是微服務？微服務如何落地？微服務的未來在哪裡？讓我們慢慢一步步梳理微服務的來龍去脈。
松耦合、自主化的微服務架構
隨著雲計算、Docker(容器)技術的發展，IT架構在不斷演進，傳統的單體應用架構已經無法滿足業務敏捷性的需求。由於應用規模日益龐大，架構需要降低耦合度，同時提高運維效率和降低成本，此外還要避免因局部故障可能對整體業務可用性造成的影響。
微服務的概念誕生於2012年。作為加快Web和移動應用程序開發進程的一種方法，從2014年開始受到各方關注。本質上講，微服務將單體應用模塊功能進行拆分，每個微服務單獨開發部署和運維，可以有效提升開發運維效率，保障整體可用性，實現持續集成與交付。
微服務是一種架構風格。一個大型複雜軟件應用由一個或多個微服務組成，系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。
微服務架構是一種創建鬆散耦合且自主化服務的新型架構風格。從業界的實踐來看，微服務核心技術架構主要包括以下幾個方面：進程間通信、服務註冊/服務發現、負載均衡、配置管理、熔斷器、API網關。以微服務架構的興起為標誌，DevOps、平臺即服務 (PaaS)、容器和持續集成與交付 (CI/CD) 方法，正在幫助企業超越面向服務的架構 (SOA) 等傳統方式，實現更大規模的模塊化系統創建和管理。
SOA 的好處是可以創建具有彈性的分佈式應用，有效消除各類複雜的中央組件。然而，SOA與組織結構高度耦合，該架構能否獲得成功在很大程度上依賴於重新規劃後的組織結構，以及設計該架構的團隊能力。有人認為，SOA創建的並非是兼具鬆散耦合和自主化特點的系統，而是一個需要複雜基礎架構的相對脆弱的系統。而且，早期的SOA實施會造成供應商鎖定，因為專有中間件往往只專注於集中化邏輯與持久化治理。
相反，微服務架構則在構建應用的每個步驟(從開發、部署到運營)中兌現了 SOA 的最初承諾，專注於簡化技術，利用精簡化的組件構建複雜系統。該架構通過基於異步HTTP或消息傳遞協議的簡單、標準化的管道通信，取代集中化邏輯和集成基礎架構(基於重量級、非標準化的平臺)。SOAP、XML 和其他重量級協議和數據格式將被輕量級 JSON所取代。每項微服務都有自己的數據存儲，不需要集中化管理和持久化。
當前主要的開源微服務框架包括Spring Cloud、Dubbo、gRPC等。我們以Spring Cloud為例來展開介紹。Spring Cloud是基於SpringBoot的一整套實現微服務的框架。它提供了微服務開發所需的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式會話和集群狀態管理等組件。更重要的是，Spring Cloud與Spring Boot框架一起使用，會讓用戶更方便地開發基於微服務架構的雲服務。SpringBoot旨在簡化創建產品級的Spring應用和服務，簡化配置文件，使用嵌入式Web服務器，含有諸多開箱即用的微服務功能。
Spring Cloud目前在Java微服務領域具有統治地位，而且有強大的社區支持。近兩年，隨著組件生態的進一步完善和生產案例的增加，Spring Cloud大有成為Java微服務框架的事實標準的趨勢。
但是作為一項開源技術，Spring Cloud得到大量開發者追捧的同時，也有自身的一些問題需要使用者去解決。比如，部分周邊組件功能不完善。Spring Cloud的開發支持界面十分友好，開發人員接受度非常高，但是Spring Cloud的配置管理、服務治理、應用發佈等環節並不完善，需要通過周邊工具完善。
國內PaaS廠商時速雲在微服務治理方面早早做好了佈局，研發出具有 Spring Cloud、 APM、 CSB、 Service Mesh 等主要能力的微服務 治理平臺，支持獨立部署在宿主機 系統， 或更加方便地通過時速雲 PaaS 平臺進行部署和管理。時速雲對 Spring Cloud 的核心組件進行了深度定製和擴展， 包括 Eureka、 Zuul、 ConfigServer、 Hys-trix、 Zipkin、 AuthServer 等。
企業如何過渡到微服務架構
目前，一些製造企業，主要是汽車製造、大型裝備製造、航空業，以及金融行業的企業已經在初步嘗試採用微服務架構。
企業如果要向微服務架構轉變過渡，應該如何做呢?
在AWS中國區的網站上提供了關於微服務應用的教程，其中一個例子是，使用微服務作為用戶應用程序負載均衡器的目標。用戶可以使用微服務架構來構造應用程序，作為可以獨立開發和部署的服務。具體來說，用戶可以在各EC2實例上安裝一個或多個這樣的服務，每個服務在不同端口上接受連接。用戶可以使用單個應用程序負載均衡器將請求路由到應用程序的所有服務。用戶將EC2實例註冊到目標組時，可以多次註冊。對於每個服務，可使用該服務的端口註冊實例。
而紅帽公司認為，若想成功採用微服務架構，企業或組織就必須首先為其單體式架構創建一個穩固的基礎，然後必須考慮和建立模塊化、域邊界和基本分佈式系統理論，以發揮微服務的全部優勢。此外，微服務還能為較複雜的系統創造更多優勢，比如DevOps、PaaS、容器、服務複製和註冊、主動監控和警告等。
企業是否已經為採用微服務做好了準備?紅帽公司建議，企業可以從以下幾個方面進行自查：是否構建了結構良好的單體式應用，是否明確了將微服務用於滿足哪些特定需求，是否圍繞微服務架構重新調整了團隊結構，是否採用了最佳DevOps和CI/CD實踐方法，是否明確界定了應用的業務範圍，是否已經實施了微服務編排和管理工具與流程等。
部署微服務，既需要協調一致、技能精湛的團隊，還需要高效的管理工具。構建一支採用扁平化組織結構，具備靈活性、多功能和自主化的高效團隊是成功應用微服務的關鍵。
構建高效率、高技能的團隊需要圍繞業務功能，而非企業架構來重新協調人員配置。例如，Amazon的“兩張披薩團隊”原則，每組團隊由8到10人組成，負責創建和維護其服務。此外，“康威定律”還指出，企業只能創造出與其組織結構相仿的設計。例如，如果對一個團隊按照開發、運營、質保和安全幾個部分進行劃分，則會對團隊的業務靈活性造成一定的限制，並可能導致進度延誤。因此，企業在過渡到微服務之前，應先創立DevOps實踐，預先明確其通信策略，從而有效緩解或防範上述問題的發生，避免創建失敗的SOA或非高效的微服務架構。
2007年，紅帽公司曾針對客戶進行過一項有關微服務應用的調查，發現當前微服務主要被用來重新架構現有的應用程序，而行業更喜歡多運行、多技術、多框架的微服務。用戶普遍接受的微服務的六大益處可以概括為：持續集成(CI)/持續部署(CD)、敏捷性、更高的可伸縮性、更快的交付時間、更高的生產效率、更容易調試和維護。但同時也必須注意落地微服務可能面對的嚴峻挑戰，包括企業文化和組織結構上的挑戰、微服務管理、診斷和監控、時間和資源管理。
紅帽公司認為，微服務架構可以為企業帶來諸多優勢，例如各種應用組件的獨立可擴展性，以及更快捷、更簡便的軟件開發與維護。但是，微服務可能無法為所有團隊或項目帶來同等的優勢。過渡到微服務是一個循序漸進的過程，僅重構部分現有應用(而非全面過渡)是切實可行的做法。為成功採用微服務架構，企業必須首先根據現有平臺標準構建和設計合理的應用，然後根據需要將應用重構為微服務集合，以滿足業務需求，同時還要配以適當的人員、流程和工具。
一句話，微服務將促進更快的開發和部署，並讓企業擺脫長期的技術鎖定，從而獲得業務發展和產品選擇的自由。
微服務的挑戰與未來
靈雀雲認為，傳統開發將面臨更加嚴峻的挑戰。
第一，研發成本高，主要體現在以下幾方面。代碼重複率高。在實際項目分工時，開發都是各自負責幾個功能，即便開發之間存在功能重疊，往往也會選擇自己實現，而不是類庫共享。主要原因是從技術架構角度看，傳統垂直架構的特點是本地API接口調用，不存在業務的拆分和互相調用，使用到什麼功能就本地開發，非常方便，不需要過度依賴於其它功能模塊。從考核角度來看，共享很難推行，只需要對自己開發的模塊交付質量負責，沒有義務為他人提供並維護公共類庫，這個非常耗費成本。跨地域、跨開發小組協調很困難，業務團隊可能跨地域研發，內部通常也會分成多個開發小組，各開發小組之間的協調和溝通成本非常高。需求變更困難。代碼重複率變高之後，已有功能變更或者新需求加入都會非常困難。以充值繳費功能為例，不同的充值渠道開發了相同的限額保護功能，當限額保護功能發生變更之後，所有重複開發的限額保護功能都需要重新修改和測試，很容易出現修改不一致或者被遺漏，導致部分渠道充值功能正常，部分存在Bug的問題。
第二，運維效率低。在傳統的MVC架構中，業務流程是由一長串本地接口或者方法調用串聯起來的，臃腫而冗長，而且往往由一個人負責開發和維護。隨著業務的發展和需求變化，本地代碼在不斷的迭代和變更，最後形成了一個個垂直的功能孤島，只有原來的開發者才理解接口調用關係和功能需求，一旦原有的開發者離職或者調到其他項目組，這些功能模塊的運維就會變得非常困難。當垂直應用越來越多時，連架構師都無法描述應用間的架構關係，隨著業務的發展和功能膨脹，這種架構很容易發生“腐化”：測試、部署成本高，業務運行在一個進程中，因此係統中任何程序的改變，都需要對整個系統重新測試並部署;可伸縮性差，水平擴展只能基於整個系統進行擴展，無法針對某一個功能模塊按需擴展;可靠性差，某個應用BUG，例如死循環、OOM等，會導致整個進程宕機。
對於微服務的未來，UMCloud認為，意識重於技術。康威法則給我們的啟示：軟件系統的接口結構會映射組織的溝通結構，如果組織架構不合理，就無法建立一個高效的系統架構。一般在系統架構調整時，要提前考慮相應的組織架構的調整，兩邊聯動才能產生效果。康威法則是近年流行的微服務架構背後的組織原理。
Adrian Cockcorft是Netflix前雲架構師，在經歷Netflix大規模微服務架構的成功實踐後，他提議現代組織要打破穀倉式職能壁壘，擁抱基於微服務的跨職能產品團隊組織模式。
目前大部分研發組織仍嚴格劃分職能，職能間交集少，標準的研發流程以產品經理和研發團隊 (包括用戶體驗團隊) 反覆多次討論新功能需求開始，研發團隊再將新功能用代碼實現，然後代碼被提交質量保證團隊進行測試。這中間又涉及雙方的多次會議交互。測試通過後提交DBA和運維上線，這中間又涉及和DBA、系統、網絡和存儲管理員的多次交互 (一般通過工單系統)，整個流程緩慢。
康威法則告訴我們，軟件系統的接口結構會反映組織的社交結構。所以如果組織要真正轉型到微服務架構，就必須圍繞微服務產品組織團隊，基於DevOps 模式開展工作。組織內不再以流水線方式設置產品經理、用戶體驗經理、研發經理等獨立職能角色。每個核心產品 (實現為微服務) 有一個經理，即負責管理和監督團隊，也負責微服務軟件研發和交付的各個環節，從概念到發佈。組織內不再有獨立的運維團隊和職能細分，只有負責基礎設施產品 (IaaS/PaaS) 的平臺團隊，提供自動化和自助式平臺 UI Portal或API，支持各個產品團隊持續交付微服務。
UMCloud在容器雲和微服務上的實踐表明，要在企業內部實施微服務架構，更多的是思維上的轉變。對於微服務架構：技術上不是問題，意識比工具重要。
一般提到微服務都離不開DevOps和Docker，理解微服務架構是核心，DevOps和Docker則是工具和手段。UMCloud認為，未來服務網格將會促進微服務的大規模落地。如果我們能夠以透明化方式在服務與網絡之間插入一個基礎設施層，藉此為運營人員提供必要的控制能力，同時幫助開發人員不必在其代碼當中引入分佈式系統帶來的專用解決方案，那麼很多挑戰將迎刃而解。正如微服務架構能夠幫助各功能團隊實現彼此解耦一樣，服務網格能夠幫助運營人員從應用程序功能開發與發佈流程當中“解耦”出來。Istio 項目即因此而生，它能夠以系統化方式將代理機制接入至網絡路徑當中，從而將不同微服務轉化為綜合性服務網格。Istio項目提供了一種統一的方法配置多種必要的功能，使得運營人員能夠更加輕鬆地運作高彈性水平服務網格。開發者在設計Istio項目時，應充分考慮到網絡內所運行的各服務的透明性，允許團隊隨著時間推移逐步採用Istio提供的各項功能。
微服務帶來的複雜度也讓很多企業頭疼，尤其是服務間通信。用戶對保證服務間通信的端到端性能和可靠性的需求，催生了下一代微服務Service Mesh。從2017年開始，Service Mesh漸漸為業內人士所熟知。作為服務間的通信層，Service Mesh可以提供更加安全、快速、可靠的服務間通信。被譽為下一代微服務的Service Mesh可能迎來爆發。
與您距離更近！
中國信息化週報（信息化時代）
官網：www.cio360.net
閱讀更多 中國信息化週報 的文章
