企業(yè)微服務架構(gòu)切入點

1、企業(yè)微服務架構(gòu)切入點企業(yè)在自身IT成熟度還沒有達到一定水平的時候，應該謹慎對待 微服務架構(gòu)，其核心原因就是由于架構(gòu)微服務化后會導致開發(fā)，集成， 乃至后期的運維管控的復雜度呈指數(shù)級提升。即使企業(yè)本身有組件化和 服務化的思想，但是也沒有能夠徹底構(gòu)建微服務架構(gòu)的能力。正如很多企業(yè)連基礎主數(shù)據(jù)都沒有管理，也沒有建設集成的研發(fā)， 生產(chǎn)相關(guān)的PLM，MES，CIM等核心系統(tǒng)，就開始談要一步邁入工業(yè)4.0 和智能制造是一樣的道理。任何事情都要考慮從簡單到復雜，通過迭代 的方式逐步演進。下面就簡單分析下企業(yè)實施微服務架構(gòu)可行的一些切 入點。共性技術(shù)服務能力下沉建設企業(yè)在剛開始規(guī)劃建設，或者建設到一定階段后，都

2、會涉及到一下 基礎性的共性技術(shù)需求，類似消息管理，日志管理，文件存儲，共性的 小應用組件（論壇，通訊錄，文檔在線閱讀）等。這些共性能力既可以是技術(shù)服務，也可以是共性小應用程序，其最 大的特點就是這些組件本身橫向交互相當少，而更多的是將自己的能力 向上提供暴露和集成。因此這類場景采用微服務架構(gòu)方式來獨立構(gòu)建并 部署是合適的，這類模塊的上線和集成可以最大限度的減少對已有橫向 業(yè)務的影響。要發(fā)現(xiàn)這類需求，企業(yè)應該有一個統(tǒng)一的需求受理和分析組，對各 個業(yè)務部門或業(yè)務系統(tǒng)提交的需求同意進行分析，抽取出共性需求，然 后再考慮是否通過微服務方式統(tǒng)一建設?；A平臺層能力先行企業(yè)在實施微服務架構(gòu)的時候，一定要意

3、識到對于4A+流程引擎這 兩個能力需要提取進行平臺化和微服務模塊化。因為這兩個基礎能力往 往是任何一個業(yè)務微服務模塊能夠運轉(zhuǎn)起來的基礎。正是由于這兩個基 礎能力的平臺化，我們在構(gòu)建新的微服務模塊的時候，才能夠?qū)⒅匦耐?全放在只關(guān)注業(yè)務實現(xiàn)上。新增模塊移出如果企業(yè)已經(jīng)實施了采購系統(tǒng)而且已經(jīng)上線運行多年，那么在對采 購系統(tǒng)出現(xiàn)大的模塊級需求的時候（例如需求在采購需求中增加招投標 的功能），那么這種模塊需求就可以考慮移出采購系統(tǒng)，通過微服務架 構(gòu)的方式獨立構(gòu)建，在構(gòu)建完成后在和采購管理系統(tǒng)集成。對于一個新增模塊是否能移出，重點還是要考慮該模塊和已有的遺 留業(yè)務系統(tǒng)間的耦合性和集成度。耦合度越小，越容

4、易單獨構(gòu)建并后期 集成。從這個角度來看對于哪些在原有業(yè)務系統(tǒng)中上游業(yè)務最適合移出， 例如招投標模塊構(gòu)建只是需要將合格供應商和采購物料清單信息傳遞 到采購系統(tǒng)，而并不需要從已有的采購系統(tǒng)返回任何信息。新增模塊移出并進行微服務化往往是對遺留系統(tǒng)影響最小的方案。 在微服務架構(gòu)在企業(yè)內(nèi)部逐步實施成熟后再考慮更多的模塊或組件從 已有系統(tǒng)中移出。大變更下模塊移出企業(yè)在接收到新的變更需求處理時，當已有業(yè)務系統(tǒng)的某一個模塊 出現(xiàn)重大變更時（比如變更內(nèi)容和范圍超過了模塊本身 30%-50%），在 這種情況下可以考慮將變更模塊移出并進行微服務架構(gòu)的改造。要清楚在模塊大變更情況下，即使按原有模塊開發(fā)和處理，也會帶 來巨大的模塊開發(fā)和集成，聯(lián)調(diào)和實施工作量，還還不如和企業(yè)微服務 架構(gòu)演進策略一起處理。兩次對業(yè)務的大影響變成一次影響，雖然增加 了復雜度，但是實際上是