如何抽取公共服務併成功遷移

博客地址

在單體到微服務架構的遷移過程當中，咱們常常會問一個問題：在什麼狀況下我須要從單體中剝離一部分出來將其做爲一個微服務？答案有不少，其中有一個答案就是：我發現好多單體都有類似的功能，我以爲能夠把它抽出來作一個公共服務。

那麼何爲公共服務？公共服務就是那些專門爲其餘服務提供服務的服務，它的業務具備高度普適性和可複用性。好比用戶服務、訂單服務就是這樣一類服務。

那咱們怎樣才能達成這一目標呢？下面舉個例子說明：

咱們發現單體A、B、C中的具備高度類似的功能F，通過初步研究發現能夠抽取出一個公共服務P，因而立刻安排人員開發，而後上線、遷移。
一切彷佛會很順利，可是等等，這裏有太多風險和未經驗證的東西。那咱們應該怎麼作？

第一步：識別不兼容

咱們須要深刻到單體A、B、C的功能F的細節中去考察，雖然功能F在各個單體中的看起來差很少，可是細節是魔鬼。
畢竟這三個單體是獨立演進的，若是深刻細節，就會發現AF、BF、CF總有一些不兼容的地方，具體表現形式能夠是數據schema不一致、接口不一致，還有更糟糕的——部分業務邏輯不一致。

這些不兼容若是一開始不識別出來，那最有可能的結果是開發人員從單體A中抽取功能F開發公共服務P，結果公共服務P只能給單體A使用，單體B、C徹底沒法使用。

第二步：設計並導入概念

識別出了不兼容，那麼咱們就須要做出一套兼容單體A、B、C的功能F的設計，在設計過程當中咱們須要和單體A、B、C的產品經理、需求設計人員、開發人員作詳盡的溝通。
作這些溝通最主要的目的就是將新的功能F的設計導入到相關人員的腦中，即所謂的概念導入。

概念導入是很是重要的一步，道理很簡單，若是你們對同一件事情的認知是同樣的，那麼這件事情就好辦了，不然在推行過程當中極可能出現不可預料的阻力。

第三步：開發類庫

好了，我們設計也作了，思想也統一了，爲何不直接開始開發服務P呢？這是由於雖然咱們在第二步已經統一了思想，可是在真正落地的時候極可能還會存在乎想不到的困難。
所以咱們要把這些困難在早期趟平，用的辦法就是提供功能F的公共類庫，將其替換掉原來單體A、B、C中的代碼。

這一工做完成後我能可以獲得的成果有：

1. 設計、概念層面造成了統一
2. 表、實體結構造成了統一
3. 接口造成了統一
4. 代碼層面的複用

也就是說，咱們作到了表裏一致，有了這個基礎，開發公共服務P纔有了真正堅實的基礎。

第四步：微服務架構設計

公共類庫的思路畢竟仍是單體應用的思路，只是作到了代碼層面的複用。當你要作公共服務P的時候就須要額外考慮一些額外的設計，好比：

1. Client的認證模式。不認證、OAuth 2.0，若是用OAuth 2.0那麼用哪一種Grant type？
2. 通訊協議。http、https、gRPC。
3. 接口協議。RESTful、SOAP。
4. 接口定義。Swagger、OpenAPI。
5. 加密方式。TLS、對稱加密。
6. 是否涉及多租戶，若是涉及，那麼還須要設計多租戶的業務、功能、數據schema。
7. 考慮服務註冊、服務發現等等。
8. 彈性設計、容錯設計、分佈式事務等等。
9. 運維相關的日誌採集、監控指標等等。

固然以上這些並非說要一次性所有作到，能夠一開始只實現一部分，以後經過迭代不斷地完善。

第五步：遷移

好了，咱們的公共服務P已經上線了，那麼如何從公共類庫遷移到公共服務P呢？

其實到這一步就很簡單了，在製做公共類庫的時候咱們應該定義了良好的接口，而且提供了一套基於單體架構的實現。
如今咱們只需提供一套基於公共服務的實現而後替換上去就能夠了。舉個例子，公共類庫有一個接口叫作UserRepository，它有一個實現是查詢本地數據庫的，咱們只需提供另外一個實現是查詢RESTful接口的就能夠了。

固然，這個查詢RESTful接口的實現最好也由公共服務P的開發團隊提供，這樣能夠避免單體A、B、C開發團隊的重複勞動。

第六步：沒有第六步

到此爲止大功告成。