微服務應用
通常在單體系統中，開發者會在類、子產品、類庫的層面來設計功能屬性，而在微服務應用中，開發者的目标則變成了可獨立部署的功能單元，而每個功能單元以一些複雜的方式進行互動，功能單元之間的互相協作則是通過一系列消息協定來完成，而這些協定可能是點對點的也可能是異步的，每個功能單元共同合作起來形成了一個更加複雜的系統
微服務發展至今已并非新鮮事物，而其定義也非常容易了解，但它确實能夠顯著的降低複雜系統開發過程中的互相牽扯和沖突，且同時具備了軟體工程實踐倡導的【高内聚】【低耦合】，很顯然具備這樣特點的系統更容易維護、易擴充，通過這些手段完成為客戶持續傳遞價值的最終目的，這裡的重點在于持續傳遞，而如果更高次元考慮，将其與商業行為結合，這個最終目的應該是為客戶快速的持續的傳遞價值，于是這裡的重點便多了一個次元即快速的持續的
微服務特點
概念是非常容易懂的，稍微有幾年開發經驗的開發者一看便知道其中的意義，但到了實操層面具體該怎麼做技術設計又無從下手，如果說微服務的概念告訴了我們它解決了什麼問題，那麼微服務的幾個特點【我更願稱之為原則】告訴了我們應該如何做技術設計
内聚度時用來衡量某個子產品中的各個元素屬于一個整體的緊密程度的名額，耦合度則是衡量一個元素對另一個元素的内部運轉邏輯了解程度的名額，而在讨論内聚和耦合的時候，單一職責原則便是一個很少的提升内聚的手段即：将那些因相同原因而修改的内容聚合到一起，将那些因不同原因而修改的内容進行拆分
單個微服務應該是高内聚的，它應該隻負責應用的一個功能，同樣每個服務對其他服務的内部運轉邏輯知道的越少就越容易修改，而不需要讓其他服務跟着一起修改
考慮一下出售股票的場景，大緻需要如下4步處理
使用者建立一個訂單，用來出售其賬戶裡某隻股票的股份
賬戶中的這部分持倉就會被預留下來，確定相同的股份不可以被多次出售
送出訂單到市場上需要繳納印花稅
系統需要将這個訂單發送給對應的股票交易市場
如圖所示微服務設計，它是整個交易系統的一部分
從圖中可以看到，微服務的三大關鍵特點：
每個微服務隻負責一個功能，這個功能可能是業務相關的功能，也可能是共用的技術功能，比如與第三方的內建
每個微服務都擁有自己的資料存儲，這是降低耦合非常關鍵的設計，各服務之間的資料通路，僅可以通過服務提供的接口來通路它們自己所不擁有的資料
微服務自己負責編排和協作(控制消息和操作的執行順序來完成某些有用的功能)，既不是由連接配接微服務的消息機制來完成的，也不是通過另外的軟體功能來完成的
除了以上的三大特點外，還有兩個基本特性：
每個微服務都可以獨立部署，如果做不到，那麼到了部署階段微服務應用還是一個龐大的單體應用，而團隊不能僅僅考慮到coding的部分，還需要考慮部署、監控、診斷等一些列環節，如此微服務才能發揮其作用
每個微服務都是可代替的，每個微服務隻具備一項功能，是以這很自然地限制了服務的大小，同時每個服務的職責或角色更加易于了解
微服務與傳統的面向服務架構soa有一個關鍵差別，微服務負責協調系統中的各個操作，而soa類型的服務通常通過使用企業服務總線esb或者更複雜的編排标準将應用本身與消息和流程編排拆開，在soa模型下，服務通常缺乏内聚度，因為業務邏輯會不斷地添加到服務總線上，而非服務本身
可以針對每個問題選擇最合适的技術工具，無需多個服務死闆的采用固有的技術和工具
自治和獨立部署意味着可以分别管理這些微服務所對應的資源需求，同時減少故障，不會因某個服務故障導緻其他服務連鎖故障
自治性也使得開發者可以獨立的對這些服務進行開發、部署和擴容
自治性、可恢複性、透明性、自動化和一緻性
非常明确的是微服務是自治的，每個服務的操作和修改都是獨立于其他服務的，那麼為了保證自治性，開發者需要将服務設計得松耦合、可獨立部署
每個微服務通過明确定義的接口或者釋出的事件消息來與其他服務進行互動，這些互動需獨立于協作方的内部實作
不同的服務通常由多個不同的團隊并行開發，是以獨立部署則成為快速傳遞價值的非常關鍵環節，也是以各服務之間相對完全獨立
自治性也是團隊文化，各個服務的責任和所有權委派給有責任傳遞商業價值的團隊，這是非常關鍵的管理決策，組織的設計會對系統設計産生影響，清晰的服務所有權有助于團隊基于他們本身所處的環境和目标疊代開發和做技術決策
微服務與生俱來的具備故障隔離的機制，如果開發者獨立的部署這些微服務，那麼當應用或者基礎設施出現故障，故障隻會影響到整個系統一部分功能，同樣部署功能的粒度越小、開發者越能更平緩的對系統進行變更
當故障發生時，開發者需要記得微服務應用是依賴于多個服務之間的互動及其表現的，而這些服務是由不同的團隊開發的，是以無論在什麼時候系統都應該是透明的、可觀測的，如此更有利于發現問題診斷問題解決問題
通過開發大量的服務來緩解應用不斷變化所帶來的痛苦，看似有悖常理，事實上相對一單體系統，微服務确實是一種更加複雜的架構，通過采用自動化和在基礎設施内保持服務之間的一緻性，開發者可以極大地降低因為這些額外的複雜性引入的管理成本，通過自動化也可以保證部署和系統運維過程中的正确性
微服務架構的流行與兩種趨勢是同時發生的，一種趨勢是devops技術的得到了主流接納，其中典型的就是**基礎設施即代碼(infrastructure-as-code)**技術；另一種趨勢是完全通過api進行程式設計的基礎設施環境(如aws和azure)的興起，三者同時發生并非巧合
以恰當的方式調整開發工作至關重要，開發者的目标應該是圍繞業務實體來組織服務和團隊，隻有如此服務和團隊的内聚性才能更高