“微服務(wù)架構(gòu)” 用來描述將軟件應(yīng)用程序設(shè)計為獨立可部署的組件化服務(wù)的一種特殊方式吧享。 討論微服務(wù)废离，需要先從傳統(tǒng)單體式應(yīng)用(monolith)說起撇寞。通俗地講呻袭，“單體應(yīng)用（monolith application）”就是將應(yīng)用程序的所有功能都打包成一個獨立的單元眨八，可以是JAR、WAR棒妨、EAR或其它歸檔格式踪古。
單體應(yīng)用程序可以在業(yè)務(wù)之初取得成功，但是隨著更多應(yīng)用程序部署到云端券腔，帶來諸多問題:
- 更改周期連在一起 - 對應(yīng)用程序的一小部分進行了更改伏穆，需要重建和部署整個整體。
- 多人共同提交一個項目纷纫，隨著時間的推移枕扫，通常很難保持良好的模塊化結(jié)構(gòu)，難以避免更新其中某個模塊的時候不對其他模塊造成影響辱魁。
- 擴展需要整個應(yīng)用程序的擴展烟瞧，而不是需要更多資源的部分。
這些挫折導(dǎo)致了微服務(wù)架構(gòu)風(fēng)格：將應(yīng)用程序構(gòu)建為服務(wù)套件染簇。 除了服務(wù)是獨立可部署和可擴展的参滴，每個服務(wù)還提供了一個穩(wěn)固的模塊邊界，甚至允許以不同的編程語言編寫不同的服務(wù)锻弓。 他們也可以由不同的團隊管理砾赔。
微服務(wù)風(fēng)格并非新穎的或創(chuàng)新的，其根源至少依賴于Unix的設(shè)計原則。
微服務(wù)架構(gòu)的特點
通過服務(wù)組件化
組件是可獨立更換和可升級的軟件單元暴心。組件之間通過HTTP協(xié)議或者RPC之類的機制進行通信妓盲。
- 使用服務(wù)作為組件（而不是庫）的一個主要原因是服務(wù)可以獨立部署。
- 更明確的組件接口专普，避免組件模塊之間過度緊密耦合悯衬。
缺點：遠程調(diào)用成本昂貴。
圍繞業(yè)務(wù)組建團隊
當將大型應(yīng)用程序分成多個部分時檀夹，管理層往往側(cè)重于技術(shù)層筋粗，導(dǎo)致UI團隊，服務(wù)器端邏輯團隊和數(shù)據(jù)庫團隊击胜。 當團隊按照這些原則分開時亏狰，會帶來如下問題：
- 即使簡單的更改也可能導(dǎo)致跨團隊項目花費時間和預(yù)算的批準。
- 一個團隊的個別成員(比如新員工)可能很難融入到他們的短期記憶中偶摔。
- 模塊化的系列需要大量的紀律執(zhí)行。
團隊圍繞業(yè)務(wù)來組建促脉，由橫向組織變更為垂直團隊辰斋，團隊是跨職能的，包括開發(fā)所需的全部技能瘸味。服務(wù)組件所需的更明確的分離使得更容易保持團隊界限清晰宫仗。
構(gòu)建產(chǎn)品而非項目
對開發(fā)人員的要求：
- 開發(fā)需要對軟件的整個生命周期負責，而非完成功能開發(fā)之后交給維護團隊旁仿。
- 開發(fā)人員需要增加一些運營支持負擔藕夫，增加與業(yè)務(wù)用戶的聯(lián)系
雖說沒有理由采用單一應(yīng)用程序不能采用同樣的方法，但是更小的服務(wù)粒度可以更容易地創(chuàng)建服務(wù)開發(fā)人員和用戶之間的個人關(guān)系枯冈。
智能端點和笨水管（dumb pipe）
替代企業(yè)服務(wù)總線 ESB毅贮。ESB產(chǎn)品通常包括用于消息路由，編排尘奏，轉(zhuǎn)換和應(yīng)用業(yè)務(wù)規(guī)則的復(fù)雜設(shè)施滩褥，承擔過多的職責。
智能端點
使用微服務(wù)思想構(gòu)建的應(yīng)用程序旨在盡可能地脫鉤和內(nèi)聚——他們擁有自己的邏輯炫加，并且更多地采用經(jīng)典Unix意義上的"過濾--接收"請求瑰煎，適當?shù)貞?yīng)用邏輯并產(chǎn)生響應(yīng)。 這些是使用簡單的REST協(xié)議編排的俗孝，而不是復(fù)雜的協(xié)議酒甸，如WS-Choreography或BPEL或由中央工具編排。
最常用的兩種協(xié)議是使用資源API和輕量級消息傳遞的HTTP請求響應(yīng)赋铝。 第一個的最好的表現(xiàn)是"成為網(wǎng)絡(luò)插勤，而非在網(wǎng)絡(luò)后面"。
通過簡單協(xié)議的資源，可以讓開發(fā)人員更方便的進行緩存饮六。
笨水管
通過輕量級消息總線進行消息傳遞其垄。 所選擇的基礎(chǔ)設(shè)施通常是愚蠢的（像僅作為消息路由器一樣愚蠢） - 諸如RabbitMQ或ZeroMQ這樣的簡單實現(xiàn)僅提供可靠的異步結(jié)構(gòu)，消息的生產(chǎn)和消費仍然由智能端點來實現(xiàn)卤橄。
將整體更改為微服務(wù)的最大問題在于改變通信模式绿满。
權(quán)力下放治理
集中治理的后果之一是將單一技術(shù)平臺標準化的趨勢。
通過權(quán)利下放窟扑，不對開發(fā)人員的平臺和技術(shù)選型形成嚴格制約喇颁，團隊負責他們構(gòu)建的軟件的所有方面，包括全天候運行軟件嚎货。
這種責任水平的下放絕對不是規(guī)范橘霎，但我們確實看到越來越多的公司將責任推向開發(fā)團隊。
分散式數(shù)據(jù)管理
數(shù)據(jù)管理的分散化包括如下方面：
- 概念模型決策
- 分散存儲策略
微服務(wù)傾向于讓每個服務(wù)管理自己的數(shù)據(jù)庫殖属。
分散管理微服務(wù)數(shù)據(jù)的責任對于管理更新具有重要意義姐叁。處理更新的常見方法是在更新多個資源時使用事務(wù)來保證一致性。這種方法通常在monolith軟件中使用洗显。使用這樣的事務(wù)有助于一致性,但這在多個服務(wù)中是有問題的外潜。分布式事務(wù)非常難以實施，因此微服務(wù)體系結(jié)構(gòu)強調(diào)了服務(wù)之間的無事務(wù)協(xié)調(diào)挠唆，明確地認識到一致性只能是最終的一致性处窥，并且通過補償操作來處理問題。
選擇以這種方式管理不一致是許多開發(fā)團隊面臨的新挑戰(zhàn)玄组，但它是經(jīng)常與業(yè)務(wù)實踐相匹配的挑戰(zhàn)滔驾。企業(yè)經(jīng)常處理一定程度的不一致，以便快速響應(yīng)需求俄讹，同時也有一些反饋過程來處理錯誤哆致。 只要修正錯誤的成本低于較大一致性下的業(yè)務(wù)損失，這個權(quán)衡是值得的颅悉。
基礎(chǔ)設(shè)施自動化
- 持續(xù)交付
- 持續(xù)集成與部署 (ci --> cd)
- 自動化測試
- 自動部署
為失敗場景進行設(shè)計
主要從監(jiān)控以及斷路器兩方面進行設(shè)計：
- 應(yīng)用程序需要設(shè)計沽瞭，以便能夠容忍服務(wù)的故障∈Ｆ浚客戶端必須優(yōu)雅回應(yīng)服務(wù)提供者的不可用導(dǎo)致的失敗情況驹溃。
- 由于服務(wù)可能隨時出現(xiàn)故障，因此能夠快速檢測故障并盡可能自動恢復(fù)服務(wù)很重要延曙。微服務(wù)期望為每個單獨的服務(wù)以及各種操作和業(yè)務(wù)相關(guān)指標看到復(fù)雜的監(jiān)控和記錄設(shè)置豌鹤。
在故障查理方面，微服務(wù)較之monolith引入了額外的復(fù)雜性
進化（升級）設(shè)計
組件的關(guān)鍵屬性是獨立替換和可升級性的概念枝缔。將組件置于服務(wù)中布疙，增加了更精細的發(fā)布計劃的機會蚊惯。
使用整體，任何更改都需要整個應(yīng)用程序的完整構(gòu)建和部署灵临。 但是截型，使用微服務(wù)器，只需要重新部署修改的服務(wù)儒溉。 這可以簡化和加速發(fā)布過程宦焦。
不利的是，必須考慮服務(wù)升級對消費者的影響顿涣。
配合接口版本管理解決波闹。
References
原文鏈接
unix哲學(xué)
- 程序應(yīng)該只關(guān)注一個目標，并盡可能把它做好涛碑。
- 讓程序能夠互相協(xié)同工作精堕。
- 應(yīng)該讓程序處理文本數(shù)據(jù)流，因為這是一個通用的接口蒲障。
更加簡化的版本是：做一件事歹篓，做好它。雖然只有第三條是特指Unix系統(tǒng)的揉阎，但Unix開發(fā)者們常常同時強調(diào)這三個信條滋捶。
軟件演進
過早的優(yōu)化是一切罪惡的根源 —— Knuth
初期由于人力/時間/業(yè)務(wù)等的壓力，采用monolith方式完成一版的設(shè)計開發(fā);業(yè)務(wù)體量到達一定程度余黎，現(xiàn)有軟件維護成本增大之后，需要考慮服務(wù)拆分载萌。
一個比較合理的拆分規(guī)則：2～3個人能夠在2~3周完成一個系統(tǒng)的迭代工作惧财。并非圭臬，但具有一定的通用性扭仁。
