微服務從幾年突然火了起來，經常在各種地方見到，剛好有空，整理了一下我的看法，我在18年開始參加作業，剛出來作業時認為微服務是一種“先進”的設計風格用上了就是好的，然而最近回頭看，微服務只是為了解決某一些問題的方案，并不適用于所有系統，選擇架構，在我看來更像是買東西：找到需要的東西，并且挑出代價最小的質量最好的，沒有過時的架構，只有合適的架構，
微服務架構
微服務是一種通過多個小型服務組合來構建單個應用的架構風格，這些服務圍繞業務能力而非特定的技術標準來構建，各個服務可以采用不同的編程語言，不同的資料存盤技術，運行在不同的行程之中，服務采取輕量級的通信機制和自動化的部署機制實作通信與運維，當系統規模大，或程式需要修改的時候，其部署的成本、技術升級的遷移成本都會變得更為昂貴，有一個很常用的解決問題思路，就是分治法：把一個大問題分成N個小問題去解決，微服務的火熱，一方面是微服務所需要的基礎設施：注冊發現、跟蹤治理、負載均衡、傳輸通信、持續集成部署已經有了很多成熟的解決方案；另一方面是越來越多的業務場景資訊化，導致我們的系統越來越龐大，
優點
- 服務自治，每一個服務都是一個獨立的小應用，可以根據需要去選擇該服務使用的編程語言、資料庫等，只需要對外介面采取一致通信協議跟格式，《人月神話》里面有一個很出名的理論，一個人10天能完成的活，加到10個人也不會1天完成，服務的拆分也有助于拆分團隊，控制單個團隊規模，增加開發效率，
- 容錯性，可靠系統完全可能由會出錯的服務組成，在微服務的設計中，有自動的機制對其依賴的服務能夠進行快速故障檢測，在持續出錯的時候進行隔離，在服務恢復的時候重新聯通，
缺點
- 資料一致性，單體服務時，資料一般都存在同一個資料庫中，資料庫能很好的保證事務，但服務拆分以后，不同服務有自己的資料庫，一個用戶請求可能需要多個資料庫，做跨庫事務是一件很頭疼的事情，
- 如何拆分才是合理的？采用服務來構建程式，獲得的收益是軟體系統“整體”與“部分”在物理層面的真正隔離，這對構筑可靠的大型軟體系統來說無比珍貴，但另一面，其付出的代價也同樣無可忽視，微服務架構在復雜性與執行性能方面做出了極大的讓步，一套由多個微服務相互呼叫才能正常運作的分布式系統中，每個節點都互相扮演著服務的生產者與消費者的多重角色，形成了一套復雜的網狀呼叫關系，對原有系統采用哪種劃分方式才能讓服務間呼叫更少更簡單？這是一個需要考慮的問題
結論
微服務更適合于業務復雜、規模龐大的系統，正如單執行緒能很好完成任務，沒必要用多執行緒，
本文來自博客園，作者：IAyue，轉載請注明原文鏈接：https://www.cnblogs.com/zmj-pr/p/14726056.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/458407.html
標籤：其他
上一篇：行為型：四. 責任鏈模式
下一篇：排查線上問題的9種方式