軟件體系架構閱讀筆記九

　　微服務不須要像普通服務那樣成爲一種獨立的功能或者獨立的資源。定義中稱，微服務是須要與業務能力相匹配，這種說法徹底正確。不幸的是，仍然意味着，若是能力模型粒度的設計是錯誤的，那麼，咱們就必須付出不少代價。若是你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是很是實用的。在決定將全部組件組合到一塊兒時，開發人員須要很是確信這些組件都會有所改變，而且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越可以靈活地下降變化和負載所帶來的影響。然而，利弊之間的權衡過程是很是複雜的，咱們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。

　　微服務做爲一項在雲中部署應用和服務的新技術已成爲當下最新的熱門話題。但大部分圍繞微服務的爭論都集中在容器或其餘技術是否能很好的實施微服務，而紅帽說API應該是重點。企業和服務提供商正在尋找更好的方法將應用程序部署在雲環境中，微服務被認爲是將來的方向。經過將應用和服務分解成更小的、鬆散耦合的組件，它們能夠更加容易升級和擴展，理論上是這樣

　　微服務的基本思想在於考慮圍繞着業務領域組件來建立應用，這些應用可獨立地進行開發、管理和加速。在分散的組件中使用微服務雲架構和平臺，使部署、管理和服務功能交付變得更加簡單。微服務是利用組織的服務投資組合，而後基於業務領域功能分解它們，在看到服務投資組合以前，它仍是一個業務領域。微服務這一律念出現於2012年，是因軟件做者Martin Fowler而流行，他認可這並無精確地定義出這一架構形式，雖然圍繞業務能力、自動化部署、終端智能以及語言和數據的分散控制有一些常見的特性。

　　開源工做流平臺 「Imixs-Workflow「發佈了一款新的微服務架構，做爲工做流來管理解決方案。Imixs的微服務（ Imixs-Microservice）提供了一個工做流封裝成微服務架構。這一服務能夠獨立於其背後的技術，綁定到任何業務應用中去。這容許業務應用改變業務邏輯的時，不用更改任何代碼。這業務目標能夠經過工做流模型控制。Imixs的微服務是基於Imixs的工做流引擎（ Imixs-Workflow Engine）的複雜功能構建的，它能夠以多種不一樣的方法來控制業務數據。Imixs的微服務能夠發送電子郵件推送消息、日誌業務交換，還能夠確保全部類型業務數據的安全。Imixs的工做流模型能夠給業務處理模型（Imixs-Workflow Modeller）中的每種狀態單獨的設計一個ACL。這許可了高度複雜的業務應用程序，並在每一個流程實例周圍駐起了安全層。