解析微服務(wù)架構(gòu)系列文章將分幾篇描述微服務(wù)的定義、特點(diǎn)、應(yīng)用場(chǎng)景、企業(yè)集成架構(gòu)的演進(jìn)以及微服務(wù)轉(zhuǎn)型思路和技術(shù)決策考慮等內(nèi)容，并以IBM技術(shù)為例介紹如何實(shí)現(xiàn)微服務(wù)架構(gòu)轉(zhuǎn)型。
為什么需要微服務(wù)架構(gòu)
“微服務(wù)”架構(gòu)是近期軟件應(yīng)用領(lǐng)域非常熱門(mén)的概念。讓我們先來(lái)看看傳統(tǒng)IT架構(gòu)面臨的一些問(wèn)題：
使用傳統(tǒng)的整體式架構(gòu)(Monolithic Architecture)應(yīng)用開(kāi)發(fā)系統(tǒng)，如CRM、ERP等大型應(yīng)用，隨著新需求的不斷增加，企業(yè)更新和修復(fù)大型整體式應(yīng)用變得越來(lái)越困難；
隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，企業(yè)被迫將其應(yīng)用遷移至現(xiàn)代化UI界面架構(gòu)以便能兼容移動(dòng)設(shè)備，這要求企業(yè)能實(shí)現(xiàn)應(yīng)用功能的快速上線；
許多企業(yè)在SOA投資中得到的回報(bào)有限，SOA可以通過(guò)標(biāo)準(zhǔn)化服務(wù)接口實(shí)現(xiàn)能力的重用，但對(duì)于快速變化的需求，受到整體式應(yīng)用的限制，有時(shí)候顯得力不從心；
隨著應(yīng)用云化的日益普及，生于云端的應(yīng)用具有與傳統(tǒng)IT不同的技術(shù)基因和開(kāi)發(fā)運(yùn)維模式。
此外，從技術(shù)方面看，云計(jì)算及互聯(lián)網(wǎng)公司大量開(kāi)源輕量級(jí)技術(shù)不停涌現(xiàn)并日漸成熟：
互聯(lián)網(wǎng)/內(nèi)聯(lián)網(wǎng)/網(wǎng)絡(luò)更加成熟；
輕量級(jí)運(yùn)行時(shí)技術(shù)的出現(xiàn)(node.js, WAS Liberty等)；
新的方法與工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；
新的輕量級(jí)協(xié)議(RESTful API接口, 輕量級(jí)消息機(jī)制)；
簡(jiǎn)化的基礎(chǔ)設(shè)施：操作系統(tǒng)虛擬化(hypervisors), 容器化(e.g. Docker), 基礎(chǔ)設(shè)施即服務(wù) (IaaS), 工作負(fù)載虛擬化(Kubernetes,Spark…)等；
服務(wù)平臺(tái)化(PaaS)： 云服務(wù)平臺(tái)上具有自動(dòng)縮放、工作負(fù)載管理、SLA 管理、消息機(jī)制、緩存、構(gòu)建管理等各種按需使用的服務(wù)；
新的可替代數(shù)據(jù)持久化模型：如NoSQL, MapReduce, BASE, CQRS等；
標(biāo)準(zhǔn)化代碼管理：如Github等。
這一切都催生了新的架構(gòu)設(shè)計(jì)風(fēng)格 – 微服務(wù)架構(gòu)的出現(xiàn)。
什么是微服務(wù)
微服務(wù)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。
微服務(wù)的概念源于2014年3月Martin Fowler所寫(xiě)的一篇文章“Microservices”(http://martinfowler.com/articles/microservices.html)。
盡管“微服務(wù)”這種架構(gòu)風(fēng)格沒(méi)有精確的定義，但其具有一些共同的特性，如圍繞業(yè)務(wù)能力組織服務(wù)、自動(dòng)化部署、智能端點(diǎn)、對(duì)語(yǔ)言及數(shù)據(jù)的“去集中化”控制等等。
微服務(wù)架構(gòu)的思考是從與整體應(yīng)用對(duì)比而產(chǎn)生的。
其中，對(duì)應(yīng)用組件封裝的方式是整體架構(gòu)與微服務(wù)架構(gòu)的主要差異，微服務(wù)架構(gòu)將相關(guān)聯(lián)的業(yè)務(wù)邏輯及數(shù)據(jù)放在一起形成獨(dú)立的邊界，其目的是能在不影響其他應(yīng)用組件(微服務(wù))的情況下更快地交付并推出市場(chǎng)。
微服務(wù)架構(gòu)的一些通用特性
根據(jù)MartinFowler的分析，微服務(wù)架構(gòu)有以下的一些通用特性，但并非所有微服務(wù)架構(gòu)應(yīng)用都必須具備所有這些特性：
通過(guò)服務(wù)實(shí)現(xiàn)應(yīng)用的組件化(Componentizationvia Services)：微服務(wù)架構(gòu)中將組件定義為可被獨(dú)立替換和升級(jí)的軟件單元，在應(yīng)用架構(gòu)設(shè)計(jì)中通過(guò)將整體應(yīng)用切分成可獨(dú)立部署及升級(jí)的微服務(wù)方式進(jìn)行組件化設(shè)計(jì)。
圍繞業(yè)務(wù)能力組織服務(wù)(Organizedaround Business Capabilities)：微服務(wù)架構(gòu)采取以業(yè)務(wù)能力為出發(fā)點(diǎn)組織服務(wù)的策略，因此微服務(wù)團(tuán)隊(duì)的組織結(jié)構(gòu)必須是跨功能的（如：既管應(yīng)用，也管數(shù)據(jù)庫(kù)）、強(qiáng)搭配的DevOps開(kāi)發(fā)運(yùn)維一體化團(tuán)隊(duì)，通常這些團(tuán)隊(duì)不會(huì)太大（如：亞馬遜的“Two pizzateam”- 不超過(guò)12人）。
產(chǎn)品而非項(xiàng)目模式(Productsnot Projects)：傳統(tǒng)的應(yīng)用模式是一個(gè)團(tuán)隊(duì)以項(xiàng)目模式開(kāi)發(fā)完整的應(yīng)用，開(kāi)發(fā)完成后就交付給運(yùn)維團(tuán)隊(duì)負(fù)責(zé)維護(hù)；微服務(wù)架構(gòu)則倡導(dǎo)一個(gè)團(tuán)隊(duì)?wèi)?yīng)該如開(kāi)發(fā)產(chǎn)品般負(fù)責(zé)一個(gè)“微服務(wù)”完整的生命周期，倡導(dǎo)“誰(shuí)開(kāi)發(fā)，誰(shuí)運(yùn)營(yíng)”的開(kāi)發(fā)運(yùn)維一體化方法。
智能端點(diǎn)與管道扁平化(Smartendpoints and dumb pipes)：微服務(wù)架構(gòu)主張將組件間通訊的相關(guān)業(yè)務(wù)邏輯/智能放在組件端點(diǎn)側(cè)而非放在通訊組件中，通訊機(jī)制或組件應(yīng)該盡量簡(jiǎn)單及松耦合。RESTful HTTP協(xié)議和僅提供消息路由功能的輕量級(jí)異步機(jī)制是微服務(wù)架構(gòu)中最常用的通訊機(jī)制。
“去中心化”治理(DecentralizedGovernance)：整體式應(yīng)用往往傾向于采用單一技術(shù)平臺(tái)，微服務(wù)架構(gòu)則鼓勵(lì)使用合適的工具完成各自的任務(wù)，每個(gè)微服務(wù)可以考慮選用最佳工具完成(如不同的編程語(yǔ)言)。微服務(wù)的技術(shù)標(biāo)準(zhǔn)傾向于尋找其他開(kāi)發(fā)者已成功驗(yàn)證解決類似問(wèn)題的技術(shù)。
“去中心化”數(shù)據(jù)管理(DecentralizedData Management)：微服務(wù)架構(gòu)倡導(dǎo)采用多樣性持久化(PolyglotPersistence)的方法，讓每個(gè)微服務(wù)管理其自有數(shù)據(jù)庫(kù)，并允許不同微服務(wù)采用不同的數(shù)據(jù)持久化技術(shù)。
基礎(chǔ)設(shè)施自動(dòng)化(InfrastructureAutomation)：云化及自動(dòng)化部署等技術(shù)極大地降低了微服務(wù)構(gòu)建、部署和運(yùn)維的難度，通過(guò)應(yīng)用持續(xù)集成和持續(xù)交付等方法有助于達(dá)到加速推出市場(chǎng)的目的。
故障處理設(shè)計(jì)(Designfor failure)：微服務(wù)架構(gòu)所帶來(lái)的一個(gè)后果是必須考慮每個(gè)服務(wù)的失敗容錯(cuò)機(jī)制。因此，微服務(wù)非常重視建立架構(gòu)及業(yè)務(wù)相關(guān)指標(biāo)的實(shí)時(shí)監(jiān)控和日志機(jī)制。
演進(jìn)式的設(shè)計(jì)(EvolutionaryDesign)：微服務(wù)應(yīng)用更注重快速更新，因此系統(tǒng)的計(jì)會(huì)隨時(shí)間不斷變化及演進(jìn)。微服務(wù)的設(shè)計(jì)受業(yè)務(wù)功能的生命周期等因素影響。如某應(yīng)用是整體式應(yīng)用，但逐漸朝微應(yīng)用架構(gòu)方向演進(jìn)，整體式應(yīng)用仍是核心，但新功能將使用應(yīng)用所提供的API構(gòu)建。再如在某微服務(wù)應(yīng)用中，可替代性模塊化設(shè)計(jì)的基本原則，在實(shí)施后發(fā)現(xiàn)某兩個(gè)微服務(wù)經(jīng)常必須同時(shí)更新，則這很可能意味著應(yīng)將其合并為一個(gè)微服務(wù)。
微服務(wù)的一些常見(jiàn)誤解
關(guān)于一些比較概念的澄清：
在同一范疇內(nèi)比較才有意義：
微服務(wù)架構(gòu) vs. SOA– 兩者都是架構(gòu)風(fēng)格范疇，但其關(guān)注領(lǐng)域與涉及范圍不同。SOA更關(guān)注企業(yè)規(guī)模范圍，微服務(wù)架構(gòu)則更關(guān)注應(yīng)用規(guī)模范圍。
微服務(wù)組件 vs. 服務(wù)組件 – 兩者都是描述業(yè)務(wù)功能的具體實(shí)現(xiàn)，其區(qū)別在于粒度不同，此外還有在可管理性、靈活性上的差異。
概念混淆的不恰當(dāng)比較
微服務(wù) vs. SOA – 不恰當(dāng)?shù)谋容^。微服務(wù)是組件范疇，而SOA是一種架構(gòu)設(shè)計(jì)風(fēng)格。因此應(yīng)該比較的是微服務(wù)架構(gòu)與SOA。
微服務(wù) vs. API – 不恰當(dāng)?shù)谋容^。 API是接口，是業(yè)務(wù)功能暴露的一種機(jī)制。微服務(wù)架構(gòu)是用于實(shí)施業(yè)務(wù)功能的組件架構(gòu)。因此直接比較它們是沒(méi)有意義的。
微服務(wù) vs. 服務(wù)– 不恰當(dāng)?shù)谋容^。“服務(wù)”在不同的場(chǎng)景下有不同的含義，需要進(jìn)一步澄清其描述的語(yǔ)境，是指服務(wù)實(shí)施、服務(wù)暴露、服務(wù)定義還是其他？微服務(wù)亦是如此，需要有特定語(yǔ)境才可判斷比較是否有意義。
微服務(wù)架構(gòu)與SOA架構(gòu)的比較
一個(gè)簡(jiǎn)單的微服務(wù)應(yīng)用例子：航班預(yù)訂應(yīng)用
將航班預(yù)訂應(yīng)用劃分為預(yù)訂航班、時(shí)間表查詢、計(jì)算票價(jià)、分配座位、管理獎(jiǎng)勵(lì)、更新客戶、調(diào)整庫(kù)存七個(gè)微服務(wù)實(shí)施。
哪些應(yīng)用會(huì)從微服務(wù)收益 ？
記錄型系統(tǒng)(System of Record)將從微服務(wù)方法中獲益最多。例如可將大型應(yīng)用按相對(duì)獨(dú)立的業(yè)務(wù)功能分解成若干個(gè)微服務(wù)實(shí)現(xiàn)。
交互型系統(tǒng)(System of Engagement)也將受益于微服務(wù)方法，例如渠道應(yīng)用可以應(yīng)用“后端服務(wù)前端”的模式實(shí)現(xiàn)。
分析型系統(tǒng)(System of Insight)則可能對(duì)微服務(wù)受益不多。其他架構(gòu)模式如管道及過(guò)濾模式可能更適用于分析型系統(tǒng)。
微服務(wù)架構(gòu)的優(yōu)點(diǎn)：
每個(gè)服務(wù)都比較簡(jiǎn)單，只關(guān)注于一個(gè)業(yè)務(wù)功能。
微服務(wù)架構(gòu)方式是松耦合的，可以提供更高的靈活性。
微服務(wù)可通過(guò)最佳及最合適的不同的編程語(yǔ)言與工具進(jìn)行開(kāi)發(fā)，能夠做到有的放矢地解決針對(duì)性問(wèn)題。
每個(gè)微服務(wù)可由不同團(tuán)隊(duì)獨(dú)立開(kāi)發(fā)，互不影響，加快推出市場(chǎng)的速度。
微服務(wù)架構(gòu)是持續(xù)交付(CD)的巨大推動(dòng)力，允許在頻繁發(fā)布不同服務(wù)的同時(shí)保持系統(tǒng)其他部分的可用性和穩(wěn)定性。
微服務(wù)架構(gòu)的缺點(diǎn)：
微服務(wù)的一些想法在實(shí)踐上是好的，但當(dāng)整體實(shí)現(xiàn)時(shí)也會(huì)呈現(xiàn)出其復(fù)雜性。
運(yùn)維開(kāi)銷及成本增加：整體應(yīng)用可能只需部署至一小片應(yīng)用服務(wù)區(qū)集群，而微服務(wù)架構(gòu)可能變成需要構(gòu)建/測(cè)試/部署/運(yùn)行數(shù)十個(gè)獨(dú)立的服務(wù)，并可能需要支持多種語(yǔ)言和環(huán)境。這導(dǎo)致一個(gè)整體式系統(tǒng)如果由20個(gè)微服務(wù)組成，可能需要40~60個(gè)進(jìn)程。
必須有堅(jiān)實(shí)的DevOps開(kāi)發(fā)運(yùn)維一體化技能：開(kāi)發(fā)人員需要熟知運(yùn)維與投產(chǎn)環(huán)境，開(kāi)發(fā)人員也需要掌握必要的數(shù)據(jù)存儲(chǔ)技術(shù)如NoSQL，具有較強(qiáng)DevOps技能的人員比較稀缺，會(huì)帶來(lái)招聘人才方面的挑戰(zhàn)。
隱式接口及接口匹配問(wèn)題：把系統(tǒng)分為多個(gè)協(xié)作組件后會(huì)產(chǎn)生新的接口，這意味著簡(jiǎn)單的交叉變化可能需要改變?cè)S多組件，并需協(xié)調(diào)一起發(fā)布。在實(shí)際環(huán)境中，一個(gè)新品發(fā)布可能被迫同時(shí)發(fā)布大量服務(wù)，由于集成點(diǎn)的大量增加，微服務(wù)架構(gòu)會(huì)有更高的發(fā)布風(fēng)險(xiǎn)。
代碼重復(fù)：某些底層功能需要被多個(gè)服務(wù)所用，為了避免將“同步耦合引入到系統(tǒng)中”，有時(shí)需要向不同服務(wù)添加一些代碼，這就會(huì)導(dǎo)致代碼重復(fù)。
分布式系統(tǒng)的復(fù)雜性：作為一種分布式系統(tǒng)，微服務(wù)引入了復(fù)雜性和其他若干問(wèn)題，例如網(wǎng)絡(luò)延遲、容錯(cuò)性、消息序列化、不可靠的網(wǎng)絡(luò)、異步機(jī)制、版本化、差異化的工作負(fù)載等，開(kāi)發(fā)人員需要考慮以上的分布式系統(tǒng)問(wèn)題。
異步機(jī)制：微服務(wù)往往使用異步編程、消息與并行機(jī)制，如果應(yīng)用存在跨微服務(wù)的事務(wù)性處理，其實(shí)現(xiàn)機(jī)制會(huì)變得復(fù)雜化。
可測(cè)性的挑戰(zhàn)：在動(dòng)態(tài)環(huán)境下服務(wù)間的交互會(huì)產(chǎn)生非常微妙的行為，難以可視化及全面測(cè)試。經(jīng)典微服務(wù)往往不太重視測(cè)試，更多的是通過(guò)監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常，進(jìn)而快速回滾或采取其他必要的行動(dòng)。但對(duì)于特別在意風(fēng)險(xiǎn)規(guī)避監(jiān)管或投產(chǎn)環(huán)境錯(cuò)誤會(huì)產(chǎn)生顯著影響的場(chǎng)景下需要特別注意。
關(guān)于微服務(wù)架構(gòu)的取舍
在合適的項(xiàng)目，合適的團(tuán)隊(duì)，采用微服務(wù)架構(gòu)收益會(huì)大于成本。
微服務(wù)架構(gòu)有很多吸引人的地方，但在擁抱微服務(wù)之前，也需要認(rèn)清它所帶來(lái)的挑戰(zhàn)。
需要避免為了“微服務(wù)”而“微服務(wù)”。
微服務(wù)架構(gòu)引入策略 – 對(duì)傳統(tǒng)企業(yè)而言，開(kāi)始時(shí)可以考慮引入部分合適的微服務(wù)架構(gòu)原則對(duì)已有系統(tǒng)進(jìn)行改造或新建微服務(wù)應(yīng)用，逐步探索及積累微服務(wù)架構(gòu)經(jīng)驗(yàn)，而非全盤(pán)實(shí)施微服務(wù)架構(gòu)。
聯(lián)系客服
