企業微服務架構切入點

企業在自身IT成熟度尚未達到必定水平的時候，應該謹慎對待微服務架構，其核心緣由就是因爲架構微服務化後會致使開發，集成，乃至後期的運維管控的複雜度呈指數級提高。即便企業自己有組件化和服務化的思想，可是也沒有可以完全構建微服務架構的能力。

 

        正如不少企業連基礎主數據都沒有管理，也沒有建設集成的研發，生產相關的PLM，MES，CIM等核心系統，就開始談要一步邁入工業4.0和智能製造是同樣的道理。任何事情都要考慮從簡單到複雜，經過迭代的方式逐步演進。下面就簡單分析下企業實施微服務架構可行的一些切入點。

 

1. 共性技術服務能力下沉建設

 

        企業在剛開始規劃建設，或者建設到必定階段後，都會涉及到一下基礎性的共性技術需求，相似消息管理，日誌管理，文件存儲，共性的小應用組件（論壇，通信錄，文檔在線閱讀）等。

 

        這些共性能力既能夠是技術服務，也能夠是共性小應用程序，其最大的特色就是這些組件自己橫向交互至關少，而更多的是將本身的能力向上提供暴露和集成。所以這類場景採用微服務架構方式來獨立構建並部署是合適的，這類模塊的上線和集成能夠最大限度的減小對已有橫向業務的影響。

 

        要發現這類需求，企業應該有一個統一的需求受理和分析組，對各個業務部門或業務系統提交的需求贊成進行分析，抽取出共性需求，而後再考慮是否經過微服務方式統一建設。

 

2. 基礎平臺層能力先行

 

        企業在實施微服務架構的時候，必定要意識到對於4A+流程引擎這兩個能力須要提取進行平臺化和微服務模塊化。由於這兩個基礎能力每每是任何一個業務微服務模塊可以運轉起來的基礎。正是因爲這兩個基礎能力的平臺化，咱們在構建新的微服務模塊的時候，纔可以將重心徹底放在只關注業務實現上。

 

3. 新增模塊移出

 

        若是企業已經實施了採購系統並且已經上線運行多年，那麼在對採購系統出現大的模塊級需求的時候（例如需求在採購需求中增長招投標的功能），那麼這種模塊需求就能夠考慮移出採購系統，經過微服務架構的方式獨立構建，在構建完成後在和採購管理系統集成。

 

        對於一個新增模塊是否能移出，重點仍是要考慮該模塊和已有的遺留業務系統間的耦合性和集成度。耦合度越小，越容易單獨構建並後期集成。從這個角度來看對於哪些在原有業務系統中上游業務最適合移出，例如招投標模塊構建只是須要將合格供應商和採購物料清單信息傳遞到採購系統，而並不須要從已有的採購系統返回任何信息。

 

        新增模塊移出並進行微服務化每每是對遺留系統影響最小的方案。在微服務架構在企業內部逐步實施成熟後再考慮更多的模塊或組件從已有系統中移出。

 

4. 大變動下模塊移出

 

        企業在接收到新的變動需求處理時，當已有業務系統的某一個模塊出現重大變動時（好比變動內容和範圍超過了模塊自己30%-50%），在這種狀況下能夠考慮將變動模塊移出並進行微服務架構的改造。

 

        要清楚在模塊大變動狀況下，即便按原有模塊開發和處理，也會帶來巨大的模塊開發和集成，聯調和實施工做量，還還不如和企業微服務架構演進策略一塊兒處理。兩次對業務的大影響變成一次影響，雖然增長了複雜度，可是其實是下降了總體工做量和後期遷移難度。

 

        企業實施微服務架構不該該是將遺留系統完全推翻並全新建設，而是應該採用3+4迭代進行的漸進式實施策略。