寫在最前
? ? ? ? 照例嘮幾句乔外，從《代碼整潔之道》就認識了Martin凤粗，也拜讀他的博客考赛，從他提起微服務就一直挺有興趣惕澎，沒能抽出時間來實戰(zhàn)寫一個練手項目，今年開年后終于各種雜事都告一段落颜骤，開始慢慢啃書啃博文就商城題材寫一個項目唧喉。項目丟github寫了一半，又要生活所迫找工作忍抽，在這里先對之前學習的內(nèi)容做一下歸納總結八孝。
概念
? ? ? ?微服務架構有別于傳統(tǒng)架構將所有功能放在一個解決方案中發(fā)布，它將功能分解成一系列松耦合的服務鸠项，這些服務通過某種協(xié)議進行互相協(xié)作完成原單體架構下的業(yè)務功能干跛，提供了更靈活的布署模式，更容易擴展锈锤，降低開發(fā)運維復雜度驯鳖。所以微服務的核心理念是分治。
? ? ? ?微服務架構將應用功能分而治之久免，使得架構上有如下優(yōu)點：1.松耦合：降低系統(tǒng)內(nèi)部重構變動對用戶的影響浅辙。2.抽象：改變某個服務的數(shù)據(jù)只依賴該服務的接口，每個服務對數(shù)據(jù)有絕對控制權阎姥，方便對數(shù)據(jù)進行控制记舆。3.獨立和更高的可用性：各個服務可以分開打包發(fā)布，獨立上下線呼巴，不影響其他服務泽腮。
? ? ? ?當然微服務也有部分缺點，比如說：1.分布式事務問題：用戶請求業(yè)務涉及多個微服務保障一致性衣赶，比如說下單涉及到訂單诊赊、商品是否可用、庫存是否充足等府瞄。2.全能對象難以拆解：訂單就是一個涉及多方的對象碧磅。3.系統(tǒng)更復雜：加大了學習難度和服務編排治理，依賴較大的服務一旦掛了會造成系統(tǒng)雪崩遵馆。
微服務拆分原則
? ? ? ? 我把拆分規(guī)則作為一個重點板塊來歸納鲸郊，因為這是微服務架構中最重要的一點，一旦沒能遵守規(guī)則拆分货邓，最后只會成為套了一份微服務殼子的單體系統(tǒng)集合秆撮。一般地，我們遵循兩條原則（出自《敏捷軟件開發(fā)：原則换况、模式與實踐》）：1.單一職責原則：原文中指一個類應該只有一個職責职辨，不應該有更多改變類形態(tài)的原因盗蟆。推理到微服務中就是微服務應該有且只有一個職責，以免造成業(yè)務之間的高耦合使業(yè)務改變時埋下不穩(wěn)定因素拨匆。2.共同封閉原則：共同封閉原文是指一個變化如果對一個封閉包產(chǎn)生變化姆涩，則將對該包所有的類產(chǎn)生影響，而不影響其他包惭每。歸納到微服務就是骨饿，我們應該將業(yè)務上聯(lián)系緊密、會因為同一個原因改變的服務放在一個微服務台腥『曜福總結下來就是將業(yè)務關聯(lián)較高的服務放在一起，除此之外全部拆分黎侈。比如說在某些應用可以根據(jù)業(yè)務將用戶服務放在一起察署，但是應用中如果有用戶服務關聯(lián)不緊密的情況也可以拆分用戶服務、拆分為登錄注冊服務等峻汉。
微服務基本構成
? ? ? 微服務架構一般會有以下幾種非功能性微服務：
? ? ? ?1.服務治理微服務贴汪，用以服務發(fā)現(xiàn)、服務注冊休吠、服務治理等扳埂。
? ? ? ?2.服務統(tǒng)一入口：用以統(tǒng)一轉發(fā)到各個服務的統(tǒng)一入口
? ? ? ?3.權限管理服務：用以管理微服務對外接口的權限驗證
? ? ? ?4.性能監(jiān)控服務：用以監(jiān)控各個微服務的健康度
? ? ? ?除了以上還有一些非功能性微服務，這里就不一一列舉了瘤礁。
微服務和SOA對比
SOA是面向服務的架構阳懂，通常是松耦合的，它將服務進行拆分柜思，通過ESB進行交互和消息調(diào)用岩调，一般地，還是整個項目級別拆分赡盘，大家用的還是相同的開發(fā)語言号枕、數(shù)據(jù)庫。
微服務則是在SOA基礎上升華陨享，每個服務都是獨立并存的葱淳，它可以是不同開發(fā)語言、不同數(shù)據(jù)庫只需要遵守同一個交互協(xié)議就可以進行互相調(diào)用霉咨。
寫在最后
? ? ? ? 對微服務的概念理解還是比較淺薄蛙紫，可能從實踐項目上更能學到東西吧拍屑，我會繼續(xù)寫那個github的練手項目的途戒。學習微服務的過程中，我參考Martin Fawler的博文僵驰、《Spring Cloud 微服務架構開發(fā)實戰(zhàn)》等資料喷斋，都是非常好的學習資料唁毒。
