delphi微服務架構
微服務架構
微服務架構區別於傳統的單體軟件架構，是一種為了適應當前互聯網后台服務的三高需求：高並發、高性能、高可用，而產生的軟件架構。
與微服務相對的另一個概念是傳統的單體式應用程序(Monolithic application)，單體式應用內部包含了所有需要的服務。而且和個服務功能模塊有很強的耦合性，也就是相比依賴彼此，很難拆分和擴容。
單體式應用程序的優點：開發簡潔，容易部署，容易測試。
單體應用程序的缺點：項目剛開始需求少，業務邏輯簡單，寫代碼一直爽，一直爽。噩夢從業務迭代更新，系統日益龐大開始，前期的爽沒有了，取而代之的是軟件維護和迭代更新的無盡痛苦。
由於單體式應用程序就像一個大型容器一樣，里面放置了許多服務，且他們是密不可分的，這導致應用程序在擴展時必須以應用程序為單位。當里面有個業務模塊負載過高時，並不能夠單獨擴展該服務，必須擴展整個應用程序，這可能導致額外的資源浪費。
相比這下，微服務架構能夠解決這個問題。
合久必分，鑒於單體應用程序有上述的缺點，單個應用程序被划分成各種小的、互相連接的微服務，一個微服務完成一個比較單一的功能，相互之間保持獨立和解耦合，這就是微服務架構。
在IT世界沒有什么技術是永不過時的，微服務架構的演進就是一個例子，從單體程序到微服務架構，我不知道下一個技術迭代點是什么時候，但我知道微服務架構肯定還會更新，IT人應該建立終身學習習慣。當然更重要的是擁有對技術的熱情，熱於擁抱變化、接受新技術，當我看到新技術我是興奮的，內心OS是厲害了，還能這么玩！而不僅僅是面向工資編程，生活會有趣很多。
微服務
微服務（Microservices）就是一些協同工作小而自治的服務。
微服務的優點
隔離性
一個服務不可用不會導致另一個服務也癱瘓，因為各個服務是相互獨立和自治的系統。這在單體應用程序中是做不到的，單體應用程序中某個模塊癱瘓，必將導致整個系統不可用，當然，單體程序也可以在不同機器上部署同樣的程序來實現備份，不過，同在存在上面說的資源浪費問題。
可擴展性
龐大的單體服務如果出現性能瓶頸只能對整體進行擴展，可能真正影響性能的只是其中一個很小的模塊，我們也不得不付出升級整個應用的代價。這在微服務架構中得到了改善，你可
以只對那些影響性能的服務做擴展升級，這樣對症下葯的效果是很好的。
簡化部署
如果你的服務是一個越大的單體服務，有幾百萬行代碼，即使修改了同行代碼也要重新編譯整個應用，這顯然是非常繁瑣的，而且軟件變更事業的不確定性非常高，軟件部署的影響也非常大。在微服務架構中，各個服務的部署是獨立的，如果真出了問題也只影響單個服務，可以快速回滾版本解決。
易優化
微服務架構中單個服務的代碼量不會很大，這樣當你需要重構或者優化這部分服務的時候，就會容易很多，畢竟，代碼量越少意味着代碼改動帶來的影響越可控。
動態擴容
一般來說，一個微服務都會部署多個實例，這樣一來能夠分擔壓力提高性能，二來即使一個實例掛了其他實例還能響應。
服務發現服務。各個微服務在啟動時自動將自己注冊到代理服務上。代理服務會定期檢查微服務的健康狀態，去掉不健康的微服務。這樣擴容時只需要部署新的微服務，微服務下線時直接關停服務即可，代理服務發現會自動檢查服務實例的增減。
客戶端負載均衡。由於微服務已經同步服務地址列表在代理服務了，所以客戶端請求服務時，代理服務可以自己決定負載策略。
