1. 首頁 > 云知道 > >

微參與app怎么樣,現在很流行微服務

云知道服務

如果所有的微服務都實現了，就有可能設計出50個微服務模塊，100個接口和集成點 。微服務架構下的運維難度增加 。微服務架構實現后，運維的復雜度也翻倍 。任何微服務模塊故障都可能影響整個業務應用的功能使用 。企業自由開發團隊實踐微服務架構 。如果企業本身的IT成熟度沒有達到一定階段，顯然是不可能實施微服務架構的 。
系統軟件架構中，現在很流行微服務，那么使用微服務就一定好么？微服務有哪些缺點呢？
下面簡單回答下這個問題 。在回答這個問題前還是先回顧下微服務架構 。微服務架構概述微服務架構本質是單個業務系統徹底的組件化前端，邏輯層，數據庫解耦，同時相互之間通過輕量的服務接口和協議進行協同 。這和很早就談到的組件化架構思想是一致的，實現微服務架構后，你會看到沒有傳統業務系統的概念了，有的只是微服務模塊或小應用 。
微服務架構最近又炒的相當活，很多人會說SOA過時了，ESB過時了，甚至還有人用微服務架構去徹底的否定SOA和ESB，這些都是相當危險的信號 。在我12，13年寫企業私有云PaaS平臺的一系列文章的時候，已經提出了業務能力組件化，組件服務化的微服務架構思想，但是實際應用實施效果并不太理想 。我們可以先看下從單體應用到微服務架構的變化圖 。
把這個核心搞清楚后，再來看下網上找到的對微服務架構的一些定義和闡述微服務可以在自己的程序中運行，并通過輕量級設備與HTTP型API進行溝通 。關鍵在于該服務可以在自己的程序中運行 。通過這一點我們就可以將服務公開與微服務架構在現有系統中分布一個API區分開來 。在服務公開中，許多服務都可以被內部獨立進程所限制 。
【微參與app怎么樣,現在很流行微服務】如果其中任何一個服務需要增加某種功能，那么就必須縮小進程范圍 。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程 。微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源 。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確 。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那么，我們就必須付出很多代價 。
如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的 。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，并且規模也會發生變化 。服務粒度越粗，就越難以符合規定原則 。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響 。然而，利弊之間的權衡過程是非常復雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題 。
在了解了微服務架構后，我們來分析下微服務架構又哪些缺點和難點 。微服務模塊拆分后，各微服務間集成復雜度指數級增加簡單舉例來說，一個企業已經實施了5個業務系統，業務系統之間有10個接口 。如果全部微服務化則可能設計到50個微服務模塊，上100個接口和集成點 ?？上攵趶氐讓嵤┪⒎蘸?，我們前期架構設計，后期集成和管控的復雜度增加10倍以上 。
這種集成難度會遠超大多數人想象，如果拿真實做的項目來說，如果談業務系統只有3個，而到微服務模塊級別則有接近60個，而實際涉及到的集成接口上1000個 。我們做任何一個復雜端到端業務的聯調基本就需要花2，3周甚至更長的時間 。互聯網企業為何適合做微服務架構，其重要的一個原因就是互聯網企業如電商平臺，在進行了微服務化后各個模塊之間耦合性很低，并不會有太多的集成和協同點 。

推薦閱讀