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