企業(yè)應(yīng)用規(guī)模日益龐大，傳統(tǒng)架構(gòu)無法有效應(yīng)對敏捷性需求，企業(yè)IT架構(gòu)亟待改變，需要降低耦合度，提高運維效率，還要避免局部故障影響整體可用性。伴隨云計算、容器（Docker）技術(shù)的發(fā)展，微服務(wù)（Microservice）應(yīng)運而生。什么是微服務(wù)？微服務(wù)架構(gòu)如何落地？微服務(wù)的未來在哪里？讓我們慢慢一步步梳理它的來龍去脈。

　　松耦合、自主化的微服務(wù)架構(gòu)

　　隨著云計算、Docker（容器）技術(shù)的發(fā)展，IT架構(gòu)在不斷演進，傳統(tǒng)的單體應(yīng)用架構(gòu)已經(jīng)無法滿足業(yè)務(wù)敏捷性的需求。由于應(yīng)用規(guī)模日益龐大，架構(gòu)需要降低耦合度，同時提高運維效率和降低成本，此外還要避免因局部故障可能對整體業(yè)務(wù)可用性造成的影響。

　　微服務(wù)的概念誕生于2012年。作為加快Web和移動應(yīng)用程序開發(fā)進程的一種方法，從2014年開始受到各方關(guān)注。本質(zhì)上講，微服務(wù)將單體應(yīng)用模塊功能進行拆分，每個微服務(wù)單獨開發(fā)部署和運維，可以有效提升開發(fā)運維效率，保障整體可用性，實現(xiàn)持續(xù)集成與交付。

　　微服務(wù)是一種架構(gòu)風(fēng)格。一個大型復(fù)雜軟件應(yīng)用由一個或多個微服務(wù)組成，系統(tǒng)中的各個微服務(wù)可被獨立部署，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個任務(wù)代表著一個小的業(yè)務(wù)能力。

　　微服務(wù)架構(gòu)是一種創(chuàng)建松散耦合且自主化服務(wù)的新型架構(gòu)風(fēng)格。從業(yè)界的實踐來看，微服務(wù)核心技術(shù)架構(gòu)主要包括以下幾個方面：進程間通信、服務(wù)注冊/服務(wù)發(fā)現(xiàn)、負載均衡、配置管理、熔斷器、API網(wǎng)關(guān)。以微服務(wù)架構(gòu)的興起為標(biāo)志，DevOps、平臺即服務(wù)(PaaS)、容器和持續(xù)集成與交付(CI/CD)方法，正在幫助企業(yè)超越面向服務(wù)的架構(gòu)(SOA)等傳統(tǒng)方式，實現(xiàn)更大規(guī)模的模塊化系統(tǒng)創(chuàng)建和管理。

　　SOA的好處是可以創(chuàng)建具有彈性的分布式應(yīng)用，有效消除各類復(fù)雜的中央組件。然而，SOA與組織結(jié)構(gòu)高度耦合，該架構(gòu)能否獲得成功在很大程度上依賴于重新規(guī)劃后的組織結(jié)構(gòu)，以及設(shè)計該架構(gòu)的團隊能力。有人認為，SOA創(chuàng)建的并非是兼具松散耦合和自主化特點的系統(tǒng)，而是一個需要復(fù)雜基礎(chǔ)架構(gòu)的相對脆弱的系統(tǒng)。而且，早期的SOA實施會造成供應(yīng)商鎖定，因為專有中間件往往只專注于集中化邏輯與持久化治理。

　　相反，微服務(wù)架構(gòu)則在構(gòu)建應(yīng)用的每個步驟（從開發(fā)、部署到運營）中兌現(xiàn)了SOA的最初承諾，專注于簡化技術(shù)，利用精簡化的組件構(gòu)建復(fù)雜系統(tǒng)。該架構(gòu)通過基于異步HTTP或消息傳遞協(xié)議的簡單、標(biāo)準(zhǔn)化的管道通信，取代集中化邏輯和集成基礎(chǔ)架構(gòu)（基于重量級、非標(biāo)準(zhǔn)化的平臺）。SOAP、XML和其他重量級協(xié)議和數(shù)據(jù)格式將被輕量級JSON所取代。每項微服務(wù)都有自己的數(shù)據(jù)存儲，不需要集中化管理和持久化。

　　當(dāng)前主要的開源微服務(wù)框架包括Spring Cloud、Dubbo、gRPC等。我們以Spring Cloud為例來展開介紹。Spring Cloud是基于SpringBoot的一整套實現(xiàn)微服務(wù)的框架。它提供了微服務(wù)開發(fā)所需的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分布式會話和集群狀態(tài)管理等組件。更重要的是，Spring Cloud與Spring Boot框架一起使用，會讓用戶更方便地開發(fā)基于微服務(wù)架構(gòu)的云服務(wù)。SpringBoot旨在簡化創(chuàng)建產(chǎn)品級的Spring應(yīng)用和服務(wù)，簡化配置文件，使用嵌入式Web服務(wù)器，含有諸多開箱即用的微服務(wù)功能。

　　Spring Cloud目前在Java微服務(wù)領(lǐng)域具有統(tǒng)治地位，而且有強大的社區(qū)支持。近兩年，隨著組件生態(tài)的進一步完善和生產(chǎn)案例的增加，Spring Cloud大有成為Java微服務(wù)框架的事實標(biāo)準(zhǔn)的趨勢。

　　但是作為一項開源技術(shù)，Spring Cloud得到大量開發(fā)者追捧的同時，也有自身的一些問題需要使用者去解決。比如，部分周邊組件功能不完善。Spring Cloud的開發(fā)支持界面十分友好，開發(fā)人員接受度非常高，但是Spring Cloud的配置管理、服務(wù)治理、應(yīng)用發(fā)布等環(huán)節(jié)并不完善，需要通過周邊工具完善。

　　國內(nèi)PaaS廠商時速云在微服務(wù)治理方面早早做好了布局，研發(fā)出具有Spring Cloud、APM、CSB、Service Mesh等主要能力的微服務(wù) 治理平臺，支持獨立部署在宿主機系統(tǒng)，或更加方便地通過時速云PaaS平臺進行部署和管理。時速云對Spring Cloud的核心組件進行了深度定制和擴展，包括Eureka、Zuul、ConfigServer、Hys-trix、Zipkin、AuthServer等。

　　國內(nèi)PaaS廠商MoPaaS認為，微服務(wù)架構(gòu)就是將一個完整的應(yīng)用從數(shù)據(jù)存儲開始，垂直拆分成多個不同的服務(wù)，每個服務(wù)都能獨立部署、獨立維護、獨立擴展，服務(wù)與服務(wù)間通過諸如RESTful API的方式互相調(diào)用。MoPaaS基于Spring Boot和Spring Cloud實現(xiàn)微服務(wù)架構(gòu)，并且各個模塊都是完全開源的。MoPaaS平臺提供注冊中心、配置中心、消息服務(wù)等組件可選，從而創(chuàng)建、編輯微服務(wù)；提供服務(wù)治理相關(guān)功能，包括服務(wù)查詢、對于服務(wù)狀態(tài)的展示、以拓撲圖直觀的展示微服務(wù)之間調(diào)用鏈、響應(yīng)時間關(guān)系等；支持啟用、禁用、分組等微服務(wù)管理功能；可以提供微服務(wù)的監(jiān)控、告警等功能，包括節(jié)點CPU、內(nèi)存等Metrics監(jiān)控與告警，以及各節(jié)點上的服務(wù)監(jiān)控與告警等。

　　企業(yè)如何過渡到微服務(wù)架構(gòu)

　　目前，一些制造企業(yè)，主要是汽車制造、大型裝備制造、航空業(yè)，以及金融行業(yè)的企業(yè)已經(jīng)在初步嘗試采用微服務(wù)架構(gòu)。

　　企業(yè)如果要向微服務(wù)架構(gòu)轉(zhuǎn)變過渡，應(yīng)該如何做呢？

　　在AWS中國區(qū)的網(wǎng)站上提供了關(guān)于微服務(wù)應(yīng)用的教程，其中一個例子是，使用微服務(wù)作為用戶應(yīng)用程序負載均衡器的目標(biāo)。用戶可以使用微服務(wù)架構(gòu)來構(gòu)造應(yīng)用程序，作為可以獨立開發(fā)和部署的服務(wù)。具體來說，用戶可以在各EC2實例上安裝一個或多個這樣的服務(wù)，每個服務(wù)在不同端口上接受連接。用戶可以使用單個應(yīng)用程序負載均衡器將請求路由到應(yīng)用程序的所有服務(wù)。用戶將EC2實例注冊到目標(biāo)組時，可以多次注冊。對于每個服務(wù)，可使用該服務(wù)的端口注冊實例。

　　而紅帽公司認為，若想成功采用微服務(wù)架構(gòu)，企業(yè)或組織就必須首先為其單體式架構(gòu)創(chuàng)建一個穩(wěn)固的基礎(chǔ)，然后必須考慮和建立模塊化、域邊界和基本分布式系統(tǒng)理論，以發(fā)揮微服務(wù)的全部優(yōu)勢。此外，微服務(wù)還能為較復(fù)雜的系統(tǒng)創(chuàng)造更多優(yōu)勢，比如DevOps、PaaS、容器、服務(wù)復(fù)制和注冊、主動監(jiān)控和警告等。

　　企業(yè)是否已經(jīng)為采用微服務(wù)做好了準(zhǔn)備？紅帽公司建議，企業(yè)可以從以下幾個方面進行自查：是否構(gòu)建了結(jié)構(gòu)良好的單體式應(yīng)用，是否明確了將微服務(wù)用于滿足哪些特定需求，是否圍繞微服務(wù)架構(gòu)重新調(diào)整了團隊結(jié)構(gòu)，是否采用了最佳DevOps和CI/CD實踐方法，是否明確界定了應(yīng)用的業(yè)務(wù)范圍，是否已經(jīng)實施了微服務(wù)編排和管理工具與流程等。

　　部署微服務(wù)，既需要協(xié)調(diào)一致、技能精湛的團隊，還需要高效的管理工具。構(gòu)建一支采用扁平化組織結(jié)構(gòu)，具備靈活性、多功能和自主化的高效團隊是成功應(yīng)用微服務(wù)的關(guān)鍵。

　　構(gòu)建高效率、高技能的團隊需要圍繞業(yè)務(wù)功能，而非企業(yè)架構(gòu)來重新協(xié)調(diào)人員配置。例如，Amazon的“兩張披薩團隊”原則，每組團隊由8到10人組成，負責(zé)創(chuàng)建和維護其服務(wù)。此外，“康威定律”還指出，企業(yè)只能創(chuàng)造出與其組織結(jié)構(gòu)相仿的設(shè)計。例如，如果對一個團隊按照開發(fā)、運營、質(zhì)保和安全幾個部分進行劃分，則會對團隊的業(yè)務(wù)靈活性造成一定的限制，并可能導(dǎo)致進度延誤。因此，企業(yè)在過渡到微服務(wù)之前，應(yīng)先創(chuàng)立DevOps實踐，預(yù)先明確其通信策略，從而有效緩解或防范上述問題的發(fā)生，避免創(chuàng)建失敗的SOA或非高效的微服務(wù)架構(gòu)。

　　2007年，紅帽公司曾針對客戶進行過一項有關(guān)微服務(wù)應(yīng)用的調(diào)查，發(fā)現(xiàn)當(dāng)前微服務(wù)主要被用來重新架構(gòu)現(xiàn)有的應(yīng)用程序，而行業(yè)更喜歡多運行、多技術(shù)、多框架的微服務(wù)。用戶普遍接受的微服務(wù)的六大益處可以概括為：持續(xù)集成（CI）/持續(xù)部署（CD）、敏捷性、更高的可伸縮性、更快的交付時間、更高的生產(chǎn)效率、更容易調(diào)試和維護。但同時也必須注意落地微服務(wù)可能面對的嚴峻挑戰(zhàn)，包括企業(yè)文化和組織結(jié)構(gòu)上的挑戰(zhàn)、微服務(wù)管理、診斷和監(jiān)控、時間和資源管理。

　　紅帽公司認為，微服務(wù)架構(gòu)可以為企業(yè)帶來諸多優(yōu)勢，例如各種應(yīng)用組件的獨立可擴展性，以及更快捷、更簡便的軟件開發(fā)與維護。但是，微服務(wù)可能無法為所有團隊或項目帶來同等的優(yōu)勢。過渡到微服務(wù)是一個循序漸進的過程，僅重構(gòu)部分現(xiàn)有應(yīng)用（而非全面過渡）是切實可行的做法。為成功采用微服務(wù)架構(gòu)，企業(yè)必須首先根據(jù)現(xiàn)有平臺標(biāo)準(zhǔn)構(gòu)建和設(shè)計合理的應(yīng)用，然后根據(jù)需要將應(yīng)用重構(gòu)為微服務(wù)集合，以滿足業(yè)務(wù)需求，同時還要配以適當(dāng)?shù)娜藛T、流程和工具。

　　一句話，微服務(wù)將促進更快的開發(fā)和部署，并讓企業(yè)擺脫長期的技術(shù)鎖定，從而獲得業(yè)務(wù)發(fā)展和產(chǎn)品選擇的自由。

　　微服務(wù)的挑戰(zhàn)與未來

　　靈雀云認為，傳統(tǒng)開發(fā)將面臨更加嚴峻的挑戰(zhàn)。

　　第一，研發(fā)成本高，主要體現(xiàn)在以下幾方面。代碼重復(fù)率高。在實際項目分工時，開發(fā)都是各自負責(zé)幾個功能，即便開發(fā)之間存在功能重疊，往往也會選擇自己實現(xiàn)，而不是類庫共享。主要原因是從技術(shù)架構(gòu)角度看，傳統(tǒng)垂直架構(gòu)的特點是本地API接口調(diào)用，不存在業(yè)務(wù)的拆分和互相調(diào)用，使用到什么功能就本地開發(fā)，非常方便，不需要過度依賴于其它功能模塊。從考核角度來看，共享很難推行，只需要對自己開發(fā)的模塊交付質(zhì)量負責(zé)，沒有義務(wù)為他人提供并維護公共類庫，這個非常耗費成本?？绲赜?、跨開發(fā)小組協(xié)調(diào)很困難，業(yè)務(wù)團隊可能跨地域研發(fā)，內(nèi)部通常也會分成多個開發(fā)小組，各開發(fā)小組之間的協(xié)調(diào)和溝通成本非常高。需求變更困難。代碼重復(fù)率變高之后，已有功能變更或者新需求加入都會非常困難。以充值繳費功能為例，不同的充值渠道開發(fā)了相同的限額保護功能，當(dāng)限額保護功能發(fā)生變更之后，所有重復(fù)開發(fā)的限額保護功能都需要重新修改和測試，很容易出現(xiàn)修改不一致或者被遺漏，導(dǎo)致部分渠道充值功能正常，部分存在Bug的問題。

　　第二，運維效率低。在傳統(tǒng)的MVC架構(gòu)中，業(yè)務(wù)流程是由一長串本地接口或者方法調(diào)用串聯(lián)起來的，臃腫而冗長，而且往往由一個人負責(zé)開發(fā)和維護。隨著業(yè)務(wù)的發(fā)展和需求變化，本地代碼在不斷的迭代和變更，最后形成了一個個垂直的功能孤島，只有原來的開發(fā)者才理解接口調(diào)用關(guān)系和功能需求，一旦原有的開發(fā)者離職或者調(diào)到其他項目組，這些功能模塊的運維就會變得非常困難。當(dāng)垂直應(yīng)用越來越多時，連架構(gòu)師都無法描述應(yīng)用間的架構(gòu)關(guān)系，隨著業(yè)務(wù)的發(fā)展和功能膨脹，這種架構(gòu)很容易發(fā)生“腐化”：測試、部署成本高，業(yè)務(wù)運行在一個進程中，因此系統(tǒng)中任何程序的改變，都需要對整個系統(tǒng)重新測試并部署；可伸縮性差，水平擴展只能基于整個系統(tǒng)進行擴展，無法針對某一個功能模塊按需擴展；可靠性差，某個應(yīng)用BUG，例如死循環(huán)、OOM等，會導(dǎo)致整個進程宕機。

　　對于微服務(wù)的未來，UMCloud認為，意識重于技術(shù)?？低▌t給我們的啟示：軟件系統(tǒng)的接口結(jié)構(gòu)會映射組織的溝通結(jié)構(gòu)，如果組織架構(gòu)不合理，就無法建立一個高效的系統(tǒng)架構(gòu)。一般在系統(tǒng)架構(gòu)調(diào)整時，要提前考慮相應(yīng)的組織架構(gòu)的調(diào)整，兩邊聯(lián)動才能產(chǎn)生效果?？低▌t是近年流行的微服務(wù)架構(gòu)背后的組織原理。

　　Adrian Cockcorft是Netflix前云架構(gòu)師，在經(jīng)歷Netflix大規(guī)模微服務(wù)架構(gòu)的成功實踐后，他提議現(xiàn)代組織要打破谷倉式職能壁壘，擁抱基于微服務(wù)的跨職能產(chǎn)品團隊組織模式。

　　目前大部分研發(fā)組織仍嚴格劃分職能，職能間交集少，標(biāo)準(zhǔn)的研發(fā)流程以產(chǎn)品經(jīng)理和研發(fā)團隊(包括用戶體驗團隊)反復(fù)多次討論新功能需求開始，研發(fā)團隊再將新功能用代碼實現(xiàn)，然后代碼被提交質(zhì)量保證團隊進行測試。這中間又涉及雙方的多次會議交互。測試通過后提交DBA和運維上線，這中間又涉及和DBA、系統(tǒng)、網(wǎng)絡(luò)和存儲管理員的多次交互(一般通過工單系統(tǒng))，整個流程緩慢。

　　康威法則告訴我們，軟件系統(tǒng)的接口結(jié)構(gòu)會反映組織的社交結(jié)構(gòu)。所以如果組織要真正轉(zhuǎn)型到微服務(wù)架構(gòu)，就必須圍繞微服務(wù)產(chǎn)品組織團隊，基于DevOps模式開展工作。組織內(nèi)不再以流水線方式設(shè)置產(chǎn)品經(jīng)理、用戶體驗經(jīng)理、研發(fā)經(jīng)理等獨立職能角色。每個核心產(chǎn)品(實現(xiàn)為微服務(wù))有一個經(jīng)理，即負責(zé)管理和監(jiān)督團隊，也負責(zé)微服務(wù)軟件研發(fā)和交付的各個環(huán)節(jié)，從概念到發(fā)布。組織內(nèi)不再有獨立的運維團隊和職能細分，只有負責(zé)基礎(chǔ)設(shè)施產(chǎn)品(IaaS/PaaS)的平臺團隊，提供自動化和自助式平臺UI Portal或API，支持各個產(chǎn)品團隊持續(xù)交付微服務(wù)。

　　UMCloud在容器云和微服務(wù)上的實踐表明，要在企業(yè)內(nèi)部實施微服務(wù)架構(gòu)，更多的是思維上的轉(zhuǎn)變。對于微服務(wù)架構(gòu)：技術(shù)上不是問題，意識比工具重要。

　　一般提到微服務(wù)都離不開DevOps和Docker，理解微服務(wù)架構(gòu)是核心，DevOps和Docker則是工具和手段。UMCloud認為，未來服務(wù)網(wǎng)格將會促進微服務(wù)的大規(guī)模落地。如果我們能夠以透明化方式在服務(wù)與網(wǎng)絡(luò)之間插入一個基礎(chǔ)設(shè)施層，借此為運營人員提供必要的控制能力，同時幫助開發(fā)人員不必在其代碼當(dāng)中引入分布式系統(tǒng)帶來的專用解決方案，那么很多挑戰(zhàn)將迎刃而解。正如微服務(wù)架構(gòu)能夠幫助各功能團隊實現(xiàn)彼此解耦一樣，服務(wù)網(wǎng)格能夠幫助運營人員從應(yīng)用程序功能開發(fā)與發(fā)布流程當(dāng)中“解耦”出來。Istio 項目即因此而生，它能夠以系統(tǒng)化方式將代理機制接入至網(wǎng)絡(luò)路徑當(dāng)中，從而將不同微服務(wù)轉(zhuǎn)化為綜合性服務(wù)網(wǎng)格。Istio項目提供了一種統(tǒng)一的方法配置多種必要的功能，使得運營人員能夠更加輕松地運作高彈性水平服務(wù)網(wǎng)格。開發(fā)者在設(shè)計Istio項目時，應(yīng)充分考慮到網(wǎng)絡(luò)內(nèi)所運行的各服務(wù)的透明性，允許團隊隨著時間推移逐步采用Istio提供的各項功能。

　　微服務(wù)帶來的復(fù)雜度也讓很多企業(yè)頭疼，尤其是服務(wù)間通信。用戶對保證服務(wù)間通信的端到端性能和可靠性的需求，催生了下一代微服務(wù)Service Mesh。從2017年開始，Service Mesh漸漸為業(yè)內(nèi)人士所熟知。作為服務(wù)間的通信層，Service Mesh可以提供更加安全、快速、可靠的服務(wù)間通信。被譽為下一代微服務(wù)的Service Mesh可能迎來爆發(fā)。

　　企業(yè)相關(guān)技術(shù)

　　UMCloud

　　UMCloud作為國內(nèi)早期涉足容器和微服務(wù)領(lǐng)域的私有云計算服務(wù)商，有自己的一套微服務(wù)產(chǎn)品，為微服務(wù)建設(shè)提供從開發(fā)到運行期的支持，主要包括以下七部分。

　　在微服務(wù)體系內(nèi)，API網(wǎng)關(guān)（Whale）提供給外部應(yīng)用訪問內(nèi)部微服務(wù)體系的總?cè)肟诰W(wǎng)關(guān)。

　　統(tǒng)一配置管理中心（Hawk），為分布式系統(tǒng)中的基礎(chǔ)設(shè)施和微服務(wù)應(yīng)用提供集中化的外部配置支持。

　　治理中心（Coral）整合了微服務(wù)框架中的注冊中心和服務(wù)治理能力，提供一站式的治理服務(wù)。

　　批量任務(wù)（Octopus）是UMCloud的彈性作業(yè)云產(chǎn)品，支持分布式定時作業(yè)、消息調(diào)度作業(yè)以及本地作業(yè)等，兼容已有Cron Table，并提供靈活的開發(fā)框架，還可與UMCloud容器云平臺無縫融合。

　　微服務(wù)中間件平臺（Nemo）是當(dāng)前企業(yè)級中間件的一體化自服務(wù)平臺，幫助加速微服務(wù)應(yīng)用的構(gòu)建。

　　異步微服務(wù)平臺（Squid）用于高并發(fā)的業(yè)務(wù)場景，Squid將同步訪問轉(zhuǎn)換成異步訪問，將訪問消息持久化保存防止丟失，實現(xiàn)微服務(wù)之間的異步調(diào)用。

　　企業(yè)級服務(wù)網(wǎng)格Service Mesh（Umesh）旨在降低微服務(wù)開發(fā)門檻，促進微服務(wù)的規(guī)?；涞?。

　　紅帽

　　企業(yè)在向微服務(wù)架構(gòu)過渡的過程中，除了設(shè)計合理的軟件和組建高效團隊之外，構(gòu)建高度可擴展的架構(gòu)還需要適合的工具，主要包括服務(wù)注冊和發(fā)現(xiàn)工具，例如Kubernetes；容器化應(yīng)用的標(biāo)準(zhǔn)化打包格式，例如Docker，以及大規(guī)模復(fù)制容器的編排工具；CI持續(xù)集成環(huán)境創(chuàng)建工具，例如Jenkins或Shippable推出的Docker and Kubernetes；依賴性解決方案，例如Nexus；故障切換和彈性工具，包括Hystrix和Ribbon等庫；服務(wù)監(jiān)控、提醒和事件工具，例如ELK（ElasticSearch、LogStash和Kibana）堆棧。紅帽O(jiān)penShift可提供滿足上述需求的可靠開源技術(shù)產(chǎn)品。

　　時速云

　　時速云是新一代容器云計算領(lǐng)域的企業(yè)，業(yè)務(wù)涵蓋容器PaaS平臺、DevOps、微服務(wù)治理、AIOps等領(lǐng)域。2018年1月，公司完成近億元B輪融資。時速云在微服務(wù)治理方面早早做好了布局，研發(fā)出具有Spring Cloud、APM、CSB、Service Mesh等主要能力的微服務(wù)治理平臺，支持獨立部署在宿主機系統(tǒng)，或更加方便地通過時速云PaaS平臺進行部署和管理。

　　時速云對Spring Cloud的核心組件進行了深度定制和擴展，包括Eureka、Zuul、ConfigServer、Hystrix、Zipkin、AuthServer等。

　　APM通過探針的方式，收集幾十種中間件的性能指標(biāo)，包括響應(yīng)時間、請求數(shù)量、負載情況、TPS等，自動生成各個中間件之間的調(diào)用關(guān)系圖及相關(guān)數(shù)據(jù)。同時也可以查看每個服務(wù)的調(diào)用情況，包括每個請求的開始時間、路徑、響應(yīng)時間、服務(wù)地址、客戶端地址，并能追蹤到具體的代碼調(diào)用堆棧情況，方便對異常請求進行迅速定位。

　　CSB相當(dāng)于微服務(wù)下的云服務(wù)總線，允許用戶發(fā)布自己的API，并定義版本和所屬的API組，或者訂閱其他用戶發(fā)布的API，支持API發(fā)布者生成API文檔。同時也可以通過CSB進行協(xié)議轉(zhuǎn)換，比如WebService同Restful之間的轉(zhuǎn)換，可以讓客戶端使用Restful接口通過CSB調(diào)用接入的SOAP服務(wù)。

　　靈雀云

　　靈雀云容器平臺使用微服務(wù)架構(gòu)輕松實現(xiàn)良好的可擴展性，同時保證隨時可升級。靈雀云容器平臺可以作為一個容器應(yīng)用，易于部署和維護，輕松集成現(xiàn)有系統(tǒng)，或快速部署新系統(tǒng)。

　　靈雀云為用戶提供支持部署和管理微服務(wù)應(yīng)用，同時可便捷維護、部署和按需擴容縮容微服務(wù)架構(gòu)。其特點在于：可伸縮性，輕松添加最常用服務(wù)的眾多實例，并刪除不經(jīng)常使用的服務(wù)實例，以保持運行環(huán)境始終處于最佳狀態(tài)；可維護性，當(dāng)升級服務(wù)時，只需重新部署必要服務(wù)，而不影響整體的用戶體驗；故障隔離，如果某個服務(wù)不可用，并不會影響系統(tǒng)的其他部分的使用功能，提供穩(wěn)定的應(yīng)用經(jīng)驗；親和性，使用最適當(dāng)?shù)恼Z言或技術(shù)，開發(fā)目標(biāo)服務(wù)，實現(xiàn)目標(biāo)而不損害平臺的實用性。

　　靈雀云微服務(wù)基于容器，相對于基于虛擬機效率更高，資源的使用率更高。靈雀云基于幾年積累的技術(shù)優(yōu)勢打造的微服務(wù)產(chǎn)品，上層應(yīng)用和底層容器、基礎(chǔ)設(shè)施之間是打通的。

　　靈雀云微服務(wù)產(chǎn)品基于開源平臺，深度支持Spring Cloud微服務(wù)框架，可平滑遷移基于Spring Cloud的微服務(wù)應(yīng)用，構(gòu)建微服務(wù)架構(gòu)和管理平臺，同時不斷優(yōu)化和定制微服務(wù)組件，在管理成本和功能方面（比如熔斷、限流等）表現(xiàn)突出。

　　郭濤

關(guān)注讀覽天下微信， 100萬篇深度好文， 等你來看……