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