微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。如果你閱讀了fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有元件組合到一起時，開發人員需要非常確信這些元件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常複雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。
微服務作為一項在雲中部署應用和服務的新技術已成為當下最新的熱門話題。但大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說api應該是重點。企業和服務提供商正在尋找更好的方法將應用程式部署在雲環境中，微服務被認為是未來的方向。通過將應用和服務分解成更小的、鬆散耦合的元件，它們可以更加容易公升級和擴充套件，理論上是這樣
微服務的基本思想在於考慮圍繞著業務領域元件來建立應用，這些應用可獨立地進行開發、管理和加速。在分散的元件中使用微服務雲架構和平台，使部署、管理和服務功能交付變得更加簡單。微服務是利用組織的服務投資組合，然後基於業務領域功能分解它們，在看到服務投資組合之前，它還是乙個業務領域。微服務這一概念出現於2023年，是因軟體作者martin fowler而流行，他承認這並沒有精確地定義出這一架構形式，雖然圍繞業務能力、自動化部署、終端智慧型以及語言和資料的分散控制有一些常見的特性。
開源工作流平台 「imixs-workflow「發布了一款新的微服務架構，作為工作流來管理解決方案。imixs的微服務（ imixs-microservice）提供了乙個工作流封裝成微服務架構。這一服務可以獨立於其背後的技術，繫結到任何業務應用中去。這允許業務應用改變業務邏輯的時，不用更改任何**。這業務目標可以通過工作流模型控制。imixs的微服務是基於imixs的工作流引擎（ imixs-workflow engine）的複雜功能構建的，它可以以多種不同的方法來控制業務資料。imixs的微服務可以傳送電子郵件推送訊息、日誌業務交換，還可以確保所有型別業務資料的安全。imixs的工作流模型可以給業務處理模型（imixs-workflow modeller）中的每種狀態單獨的設計乙個acl。這許可了高度複雜的業務應用程式，並在每個流程例項周圍駐起了安全層。
軟體體系架構閱讀筆記十四
在服務化系統或者微服務架構中，我們如何拆分服務才是最合理的？服務拆分到什麼樣的粒度最合適？按照微服務的初衷，服務要按照業務的功能進行拆分，直到每個服務的功能和職責單一，甚至不可再拆分為止，以至於每個服務都能獨立部署，擴容和縮容方便，能夠有效地提高利用率。拆得越細，服務的耦合度越小，內聚性越好，越適合...
軟體體系架構閱讀筆記十三
3.限流模式 服務的容量和效能是有限的，在第3章中會介紹如何在架構設計過程中評估服務的最大效能和容量，然而，即使我們在設計階段考慮到了效能壓力的問題，並從設計和部署上解決了這些問題，但是業務量是隨著時間的推移而增長的，突然上量對於乙個飛速發展的平台來說是很常見的事情。針對服務突然上量，我們必須有限流...
軟體架構閱讀筆記01
進行軟體架構的學習，先粗略的讀一遍 大型 架構 了解軟體架構。大致明白了幾點，首先利用軟體架構 解決問題，解決業務問題，進行優化，然而架構不能夠解決所有問題。其次，軟體架構只有親身經歷從低到高才能夠了解架構，我只能夠粗略理解，沒有實際進行，不能深入解讀。軟體架構主要講的內容之一就是 分類。也就是軟體...