資訊專欄INFORMATION COLUMN
摘要：那我們怎樣才能達成這一目標呢下面舉個例子說明我們發現單體中的具有高度相似的功能，經過初步研究發現可以抽取出一個公共服務，于是馬上安排人員開發，然后上線遷移。
博客地址
在單體到微服務架構的遷移過程中，我們經常會問一個問題：在什么情況下我需要從單體中剝離一部分出來將其作為一個微服務？答案有很多，其中有一個答案就是：我發現好多單體都有相似的功能，我覺得可以把它抽出來做一個公共服務。
那么何為公共服務？公共服務就是那些專門為其他服務提供服務的服務，它的業務具有高度普適性和可復用性。比如用戶服務、訂單服務就是這樣一類服務。
那我們怎樣才能達成這一目標呢？下面舉個例子說明：
我們發現單體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中的代碼。
這一工作完成后我能能夠得到的成果有：
設計、概念層面形成了統一
表、實體結構形成了統一
接口形成了統一
代碼層面的復用
也就是說，我們做到了表里一致，有了這個基礎，開發公共服務P才有了真正堅實的基礎。
第四步：微服務架構設計
公共類庫的思路畢竟還是單體應用的思路，只是做到了代碼層面的復用。當你要做公共服務P的時候就需要額外考慮一些額外的設計，比如：
Client的認證模式。不認證、OAuth 2.0，如果用OAuth 2.0那么用哪種Grant type？
通信協議。http、https、gRPC。
接口協議。RESTful、SOAP。
接口定義。Swagger、OpenAPI。
加密方式。TLS、對稱加密。
是否涉及多租戶，如果涉及，那么還需要設計多租戶的業務、功能、數據schema。
考慮服務注冊、服務發現等等。
彈性設計、容錯設計、分布式事務等等。
運維相關的日志采集、監控指標等等。
當然以上這些并不是說要一次性全部做到，可以一開始只實現一部分，之后通過迭代不斷地完善。
第五步：遷移
好了，我們的公共服務P已經上線了，那么如何從公共類庫遷移到公共服務P呢？
其實到這一步就很簡單了，在制作公共類庫的時候我們應該定義了良好的接口，并且提供了一套基于單體架構的實現。
現在我們只需提供一套基于公共服務的實現然后替換上去就可以了。舉個例子，公共類庫有一個接口叫做UserRepository，它有一個實現是查詢本地數據庫的，我們只需提供另一個實現是查詢RESTful接口的就可以了。
當然，這個查詢RESTful接口的實現最好也由公共服務P的開發團隊提供，這樣可以避免單體A、B、C開發團隊的重復勞動。
第六步：沒有第六步
到此為止大功告成。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11911.html
摘要：如果我們可以克服一些數據遷移的挑戰，將一個數據倉庫以及其數據分析工具從數據中心中的專用服務器轉移到基于云的文件系統和數據庫就可以解決這個問題。數據遷移工具輔助向云端遷移從數據庫抽取數據很容易，從數據庫中有效挖掘大容量數據確是一項挑戰。 云計算和數據倉庫是合理的一對。云存儲可以按需擴展，云可以將大量服務器貢獻于某一具體任務。數據倉庫通用功能是本地數據分析工具，受到計算和存儲 資源的限制，同時也...
摘要：如果我們可以克服一些數據遷移的挑戰，將一個數據倉庫以及其數據分析工具從數據中心中的專用服務器轉移到基于云的文件系統和數據庫就可以解決這個問題。數據遷移工具輔助向云端遷移從數據庫抽取數據很容易，從數據庫中有效挖掘大容量數據確是一項挑戰。 云計算和數據倉庫是合理的一對。云存儲可以按需擴展，云可以將大量服務器貢獻于某一具體任務。數據倉庫通用功能是本地數據分析工具，受到計算和存儲資源的限制，同時也受...
摘要：由服務器提供的響應來自服務器響應的狀態碼來自服務器響應的狀態信息服務器響應的頭是為請求提供的配置信息所以請求返回后，我們可以通過來獲取響應情況。攔截器攔截器攔截器用于攔截發起的請求或用于攔截返回的響應。目錄 上節內容回顧 使用第三方組件庫 如何發起請求 請求錯誤處理 請求帶參 ...
摘要：不過，根據近期的一份調查問卷表示，在所有的參與者之中，只有的組織對于他們的云遷移體驗感到非常滿意。在本文中，我們將探索整個云遷移周期中的四個階段?？梢钥隙ǖ氖?，云遷移是一項不會真正結束的任務。 軟件組織正在快速地實施云技術，但遷移始終是一個無法回避的挑戰。哪些部分是需要你密切留意的？哪些應用程序更適合于進行遷移？如何對應用程序進行重構以適用于云端？經歷了這一轉變的先行者為我們留下了什么啟示？...
摘要：背景在一個數據庫中存在表與表，但兩個表按目前架構邊界劃分的話，是屬于兩個組織下的兩個系統，導致相互之間有穩定性風險。為增強系統穩定性，進行存儲分離。準備將表的所有數據，遷移到新庫中。背景:? ? ?在一個數據庫中存在A表與B表，但AB兩個表按目前架構邊界劃分的話，是屬于兩個組織下的兩個系統，導致相互之間有穩定性風險。為增強系統穩定性，進行存儲分離。準備將B表的所有數據，遷移到新庫中?？赡艽嬖?..
閱讀 553·2023-04-26 02:59
閱讀 691·2023-04-25 16:02
閱讀 2154·2021-08-05 09:55
閱讀 3543·2019-08-30 15:55
閱讀 4640·2019-08-30 15:44
閱讀 1797·2019-08-30 13:02
閱讀 2193·2019-08-29 16:57
閱讀 2288·2019-08-26 13:35
