企業(yè)微服務(wù)架構(gòu)切入點(diǎn)

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

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

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

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