混合微服務模式
原作者：Sonya Koptyev
原標題：Why a Microservices Hybrid Model Is What You Probably Need Instead
在聽到別人談及微服務 的時候，你會注意到他們討論的是一個非此即彼的問題：重構成微服務？還是固守單體形態？這種想法很合情理：微服務是個複雜的話題，把這個複雜性簡化成一個二選一問題，就輕鬆了。
然而微服務實際上並不是一個非黑即白的概念。在應用中部分使用微服務，其它元件仍然保持單體應用的狀態，這是一種完全有可能的情況。
這就成了一種混合模式的微服務。本文中我希望能解釋一下混合微服務的具體含義，為什麼會用到這種模式以及如何構建混合模式的微服務。
混合微服務的概念和來由
簡單來說，混合微服務應用 意味著應用的一部分是用微服務的方式來進行開發和部署，其它部分則還是單體形式。
可以將其與混合雲相類比，混合雲中包含了公有云、私有云，可能還有其它的自有基礎設施。目前來看，混合雲是一種流行的實踐方式；實際上，可能很難找到一個完全單一雲模式的組織。
如果我們能和混合雲共處，那麼也應該能夠應對混合微服務架構。這種做法能夠比較簡單的獲得微服務在彈性、容量和安全方面的好處，又無需使用微服務架構將傳統應用完全重構。
對多陣列織來說，將一個單體應用完全重構為微服務的過程中，對開發資源的調動是一個很嚴峻的問題；採用混合微服務策略是一個較好的方式，對開發團隊來說，這種方式讓微服務架構觸手可及；否則的話，開發團隊可能會因為時間、經驗等方面的欠缺，無法接受對單體應用的重構工作。
構建混合微服務架構的最佳實踐
混合微服務架構的基本概念很容易理解，但是實現起來就頗值得玩味了。首先面臨的問題就是，需要對你的應用進行鑑別——哪些部分需要微服務改造，哪些部分需要保持單體形態。這裡給出一些提示。
最大化收益的部分優先重構
最醒目也是最重要的事情就是，應用的哪些部分重構為微服務會獲得最大收益。
哪些部分需要重構？要解答這個問題很明顯根據實際情況來進行判斷，但是還是存在一些指導性的微服務改造原則的：
- 伸縮性 ：你的應用中，可能有些部分需要比其它部分更多的例項數量。例如一個系統的首次訪問可能需要登入，這就可能使得認證模組在某一時間出現峰值，而其它模組則不存在這種波動。這種情況下，將認證模組拆分出來形成獨立的微服務，就能讓你用更少資源來滿足認證的峰值需要。
- 安全性：應用中哪一部分最多暴露在安全威脅之下？哪一部分最有可能被入侵從而影響到其它部分的安全？這些元件應該優先轉換為微服務，這樣有利於進行有效的隔離，降低安全風險。
- 更新：微服務的一個重要優勢就是能夠在不打擾其它微服務的情況下進行獨立更新。有時一個應用中的不同元件會有不同的更新頻率。有時候你會在很少更新後端的情況下，頻繁的變更介面。這種情況下，可以把前端重構為一個或多個微服務，從而能夠更容易的進行這部分的更新工作，讓原有的後端繼續以單體應用的形式進行。
正視微服務的複雜性
微服務有很多優勢，但是也有其固有的缺陷：把系統變得更復雜。這種額外的複雜性，直接提升了開發和運維工作的難度。
正因如此，混合微服務的方式就很有意義了，可以儘可能的降低微服務引入的複雜性。例如哪一部分的 API 呼叫更少，或者哪一部分可以打包為獨立的容器。如果優先對這些元件進行重構，就能夠有效的減少 API 呼叫，降低容器化的難度。
面向未來
和混合雲一樣，混合微服務策略不是一蹴而就的。這是個持續的過程。可能起初只有一小部分的元件被獨立出來成為了微服務，從而形成了混合微服務架構，但是不必止步於此，隨著時間的推移和環境的變化，可能會有更多的重構需求。
所以在踏上混合微服務之路的時候，應該設計一個微服務的路線圖。就算不具體到時間，至少也應該對你的混合微服務應用有一個基本的演進設想。
結論
我們都希望改善我們的單體應用，但實際情況是，多數情況下我們不會有足夠的開發資源把單體應用迅速的重構為微服務架構。與其全盤放棄，不如考慮一下這種混合微服務架構。可以參考上面提出的標準，來決定需要進行微服務改造的模組，需求不夠迫切的其它部分，繼續以單體應用的模式提供服務。