微服務可以運行在自己的程序中，通過輕量級設備與HTTP API進行通信。關鍵是服務可以在自己的程序中運行。通過這個，我們可以區分服務公開和微服務架構(在現有系統中分發壹個API)。在服務公開中，許多服務可以受到內部獨立流程的限制。如果這些服務中的任何壹個需要增加壹些功能，那麽流程的範圍就必須縮小。在微服務架構中，只需要將所需的功能添加到特定的服務中，而不會影響整個流程架構。
中文名
微服務架構
外國名字
微服務
操作平臺
imixs-工作流
屬性
Seneca是壹個構建微服務框架的工具。
狀態
眼下最新的熱門話題
快的
航行
現狀？特色？服務平臺？工具開發
概念
微服務不需要像普通服務壹樣是獨立的功能或者獨立的資源。根據定義，微服務需要與業務能力相匹配，這是完全正確的。不幸的是，這仍然意味著如果能力模型的粒度設計是錯誤的，那麽我們必須付出很大的代價。如果妳讀完福勒的整篇文章，妳會發現其中的指導和建議非常實用。當決定將所有組件放在壹起時，開發人員需要非常有信心，這些組件會發生變化，規模也會發生變化。服務粒度越粗，越難滿足規定的原則。服務粒度越細，越能靈活降低變更和負載的影響。但利弊權衡過程非常復雜，要在分配和資本模型的基礎上考慮基礎設施的成本。[1]
狀態
微服務作為壹種在雲中部署應用和服務的新技術，已經成為最新的熱門話題。但圍繞微服務的爭論大多集中在容器或其他技術能否很好地實現微服務，紅帽說API應該是重點。
企業和服務提供商正在尋找更好的方式在雲環境中部署應用，微服務被認為是未來的方向。通過將應用程序和服務分解成更小的、松散耦合的組件，它們可以更容易地升級和擴展，理論上就是這樣。