目錄
微服務今天簡單了解一下微服務，在看微服務前，先了解一下傳統的單機系統。
所有的業務子模組都集中在乙個系統中，優點是便於管理，但是規模變大的時候，缺點就很明顯了。
缺點：當產品規模越來越大，各種的大大小小模組都塞在乙個專案中，必然會使整個專案變的臃腫，讓開發者難以維護。
系統的各個功能模組都依賴於同樣的資料庫、記憶體等資源、一旦某個功能模組對資源處理不當，即可能影響整個系統。
當系統的訪問量越來越大的時候，單體系統可以進行水平擴充套件，部署多台機器。
但是這種擴充套件並不靈活，假如我們的效能瓶頸在支付上，只希望對支付模組進行水平擴充套件，單體系統是無法做到的。
微服務，是近年來流行起來的一種架構思想，將單個的應用拆分成一套小型服務，每種應用都是乙個獨立的程序，通過輕量級機制(通常為http資源api)進行通訊。
這些服務圍繞業務功能構建，由於程序的獨立性，這些小型服務可以使用不同的程式語言、資料儲存技術。
微服務的優點
單體架構是以整個系統作為單位部署，而微服務則可以作為乙個獨立的元件單獨部署。
舉個例子，我們都知道每年雙11的爆發訪問量，而且基本會集中在凌晨。
那麼假如系統瓶頸在於支付模組，需要300臺機器，其次是訂單只需要200臺，使用者只需要100臺機器，那麼我們採用微服務的話就可以進行如下部署。同時docker的流行，也為微伺服器提供了有效的容器。
微服務的乙個重要設計原則就是每乙個微服務擁有獨立的資料來源，假如訂單服務想讀取使用者服務的資料庫，那麼只能通過操作使用者服務的介面完成。
同時，docker容器也做好了資源的有效隔離。
相比於傳統架構，微服務架構更強調的是系統按業務邊界做細粒度的拆分和部署。
那麼微服務架構有哪些缺點呢：
微服務需要把原有的系統拆分成多個獨立工程，同時需要保證不同服務之間的資料一致性，引入了分布式事務和非同步補償機制，大大增加了設計和開發的難度。
微服務拆分過細可能會出現新增乙個小功能需要改動好幾個工程的情況，隨著服務數量的增加，管理的複雜性也會隨之增加。
所以說架構設計沒有什麼絕對的，主要還是看場景，如果不在大廠的話，一般很難遇到複雜的微服務架構吧。
微服務 微服務簡介
什麼是微服務 顧名思義，就是粒度較小的服務，不再侷限於系統與系統之間的藉口呼叫，也不侷限於某種具體的服務形式。系統中凡是可被復用的功能模組都可以被 服務化 轉變為 服務 這些服務可以對外暴露，也可能僅限於再系統內部使用。由於服務數量更多，粒度更小，因此管控難度會更大，對效能的要求也更高。微服務的好處...
微服務學習筆記 什麼是微服務
martin fowler 簡而言之，微服務架構風格這種開發方法，是以開發一組小型服務的方式來開發乙個獨立的應用系統的。其中每個小型服務都執行在自己的程序中，並經常採用http資源api這樣輕量的機制來相互通訊。這些服務圍繞業務功能進行構建，並能通過全自動的部署機制來進行獨立部署。這些微服務可以使用...
微服務實踐 什麼是微服務
微服務是一種軟體架構風格，該詞 於martin fowler 的一篇部落格。他在自己部落格中闡述了微服務六個特點 創業初期 很快完成後，找了家雲服務部署上線，開始了創業之路。規模擴大 這一階段存在著很多不合理的地方 做出改變 在程式設計的世界裡，最重要的是抽象能力，通過整理業務邏輯，抽象初公共的業務...