對於微服務和容器雲是雲原生技術中的兩個關鍵內容。
企業傳統IT架構的中臺化或微服務化，本身有明確的業務目標和業務場景驅動，簡單來說就是共性業務能力下沉，上層應用能夠組合或編排來進行構建，以敏捷的響應上層的業務需求和變化。因此傳統架構的微服務化往往是先行的。
在微服務化後你會發現管理的微服務太多，對於編譯，構建，打包部署等都是巨大的工作量，必須透過自動化進行持續整合，同時由於微服務化後本身也更加適合透過容器部署，因此才由需求驅動進一步實施DevOps和容器雲平臺建設。
企業微服務架構的切入點前面兩篇文章我講解了企業在自身IT成熟度還沒有達到一定水平的時候，應該謹慎對待微服務架構，其核心原因就是由於架構微服務化後會導致開發，整合，乃至後期的運維管控的複雜度呈指數級提升。即使企業本身有元件化和服務化的思想，但是也沒有能夠徹底構建微服務架構的能力。
正如很多企業連基礎主資料都沒有管理，也沒有建設整合的研發，生產相關的PLM，MES，CIM等核心系統，就開始談要一步邁入工業4.0和智慧製造是一樣的道理。任何事情都要考慮從簡單到複雜，透過迭代的方式逐步演進。下面就簡單分析下企業實施微服務架構可行的一些切入點。
共性技術服務能力下沉建設
企業在剛開始規劃建設，或者建設到一定階段後，都會涉及到一下基礎性的共性技術需求，類似訊息管理，日誌管理，檔案儲存，共性的小應用元件（論壇，通訊錄，文件線上閱讀）等。
這些共效能力既可以是技術服務，也可以是共性小應用程式，其最大的特點就是這些元件本身橫向互動相當少，而更多的是將自己的能力向上提供暴露和整合。因此這類場景採用微服務架構方式來獨立構建並部署是合適的，這類模組的上線和整合可以最大限度的減少對已有橫向業務的影響。
要發現這類需求，企業應該有一個統一的需求受理和分析組，對各個業務部門或業務系統提交的需求同意進行分析，抽取出共性需求，然後再考慮是否透過微服務方式統一建設。
基礎平臺層能力先行
企業在實施微服務架構的時候，一定要意識到對於4A+流程引擎這兩個能力需要提取進行平臺化和微服務模組化。因為這兩個基礎能力往往是任何一個業務微服務模組能夠運轉起來的基礎。正是由於這兩個基礎能力的平臺化，我們在構建新的微服務模組的時候，才能夠將重心完全放在只關注業務實現上。
新增模組移出
如果企業已經實施了採購系統而且已經上線執行多年，那麼在對採購系統出現大的模組級需求的時候（例如需求在採購需求中增加招投標的功能），那麼這種模組需求就可以考慮移出採購系統，透過微服務架構的方式獨立構建，在構建完成後在和採購管理系統整合。
對於一個新增模組是否能移出，重點還是要考慮該模組和已有的遺留業務系統間的耦合性和整合度。耦合度越小，越容易單獨構建並後期整合。從這個角度來看對於哪些在原有業務系統中上游業務最適合移出，例如招投標模組構建只是需要將合格供應商和採購物料清單資訊傳遞到採購系統，而並不需要從已有的採購系統返回任何資訊。
新增模組移出並進行微服務化往往是對遺留系統影響最小的方案。在微服務架構在企業內部逐步實施成熟後再考慮更多的模組或元件從已有系統中移出。
大變更下模組移出
企業在接收到新的變更需求處理時，當已有業務系統的某一個模組出現重大變更時（比如變更內容和範圍超過了模組本身30%-50%），在這種情況下可以考慮將變更模組移出並進行微服務架構的改造。
要清楚在模組大變更情況下，即使按原有模組開發和處理，也會帶來巨大的模組開發和整合，聯調和實施工作量，還還不如和企業微服務架構演進策略一起處理。兩次對業務的大影響變成一次影響，雖然增加了複雜度，但是實際上是降低了整體工作量和後期遷移難度。
企業實施微服務架構不應該是將遺留系統徹底推翻並全新建設，而是應該採用3+4迭代進行的漸進式實施策略。
全新構建模式-平臺建設微服務架構思想實際上是包含了平臺+應用思想，業務元件化服務化思想，SOA和雲思想，包括當前主流的DevOps思想的一個融合，而不僅僅是簡單的微服務架構。因此對於一個新建立的企業要基於微服務架構思想來整體規劃內部IT並不是一件容易的事情。
首先我們對整體規劃建設進行拆分，主要應該包括以下關鍵的建設任務和內容。
底層私有云平臺建設：這個即考慮全部基於IaaS資源池進行並儘量去IOE架構，當前實際上對於涉及到資料庫仍然或涉及到部分的Oracle資料庫和集中儲存，企業在選型和規劃的時候要考慮本身去掉這部分潛在風險。伺服器資源可以考慮全部採用X86伺服器並進行虛擬化，提供虛擬機器資源作為計算能力。
容器化PaaS平臺建設：對於PaaS平臺建設當前可以基於輕量的Docker容器進行，並透過Kubernates進行資源管理和動態排程。而如果規劃建設DevOps支撐平臺，即在DevOps平臺建設過程中統一建設容器化PaaS平臺，當然在DevOps平臺中會進一步實現了持續整合和流水線作業能力，實現開發，執行和後期運維監控的一體化管理。透過實施DevOps平臺可以進一步對當前的開發團隊規劃，崗位角色分工，軟體過程改進等進一步最佳化。
技術標準和規範體系建設：在微服務架構實施中，還有一個重點就是制定微服務架構開發框架，標準和規範體系。以指導後續開發廠商按照統一的標準方法，工具和流程進行微服務元件模組和介面服務的開發，確保開發標準和規範一致性，也進一步確保了後續多個微服務模組在整合的時候不會出現問題。
把這些都談後，再轉回談需要統一建設的技術平臺部分。
公共流程平臺：這個公共流程平臺也是必須，實現統一的類似內部多租戶的流程引擎，實現流程的設計建模，執行，監控的全部統一化。各個業務元件模組僅僅是使用流程平臺提供的能力。
技術服務平臺：這個實際涉及到訊息，快取，檔案，任務，日誌，通知，分散式儲存等諸多技術服務能力，可以根據企業需要來確定哪些要單獨實現為獨立的技術服務能力開放提供。這個沒有明確的要求，但是根據實際專案實踐來看，類似傳送簡訊郵件的通知類服務，檔案儲存類服務往往都是必須要規劃建設的。
監控運維平臺：這個平臺實際上包括了傳統的IT網管監控，同時還包括了當前的APM業務效能監控兩個方面的內容。同時兩者內容本身又相互整合和融合。由於採用了容器化PaaS，實際上微服務開發商對底層資源的情況並不清楚，因此更加需要這樣一個監控運維平臺能夠同時監控到業務效能和資源層效能，並實時預警。
對於4A平臺和流程平臺實際是企業內部私有云平臺的一個差異化點，當前公有云廠商技術服務能力也很少提供這兩塊內容，即以上兩個平臺雖然和具體業務無關，但是本身又和業務存在耦合和相關性，因此不能完全算做技術服務，更好的說法是公共服務能力。
除了技術平臺外，再來看下業務中臺部分可以規劃建設哪些內容。
主資料平臺建設：基於當前企業資訊化規劃建設實施，對於業務中臺部分能夠統一考慮的只有基礎主資料部分內容，因為這部分是共性基礎資料服務提供能力。當然基於微服務架構模式下，實際上也沒有獨立的主資料平臺概念，實際上應該只有類似供應商，產品，客戶等微服務模組。
在完全微服務架構化下，實際上沒有主資料平臺的概念，主資料平臺能力本身分散到各個微服務中去完成，類似使用者中心，商品中心等。同時新架構下主資料不再需要多點同步和整合，而是按需實時訪問和獲取，資料不多個系統落地。而對於需要資料採集整合提供整合後資料服務能力這塊，已經遷移到新的類似資料中臺中去完成。
中間即是滿足各個業務能力實現的微服務模組應用，相互獨立自治，松耦合。微服務模組間透過輕量的Http API即可進行互動和協同。當然在這個過程中涉及到微服務閘道器的使用等。
最上層統一門戶平臺建設：對於最上層，需要統一規劃建設即是統一門戶平臺，門戶平臺重點就是實現業務功能在應用層的簡單組裝和配置，類似App Store商店一樣，最終的業務使用者可以根據自己的需求安裝相關的業務系統應用。即門戶具備足夠的靈活定製能力。同時對於DevOps平臺最好和前端門戶結合，即透過DevOps平臺釋出和部署的微服務可以直接釋出到最終的門戶應用上面。
遺留架構遷移-場景分析對於遺留的單體應用，要進行微服務架構的改造往往比一個全新應用基於微服務架構實現更加困難。對於單體應用的微服務架構改造，最常見的方式仍然是將低耦合的模組逐步遷出。下面以一個採購系統中招投標模組遷出為例進一步思考單體應用的微服務架構改造步驟。
在整個模型中我們將模型進行簡化，當遷出一個功能模組進行微服務化的時候，首先要考慮的就是對該模組進行整合架構分析，考慮該模組和外圍的整合情況，其次才是考慮該模組內部的私有資料。
對於招投標模組我們將模型簡化來看，主要涉及到上游，下游和底層共享資料幾個方面的整合，初步分析如下：
1. 上游需要整合專案管理系統中專案資訊，招投標基於已經立項的專案資訊。2. 下游需要整合當前遺留的採購系統，其中招投標結果資訊和認證合格的供應商資訊需要同步到採購模組。3. 底層業務需要呼叫供應商，企業組織，人員等基礎資料資訊。4. 底層技術需要呼叫流程引擎能力，實現招投標模組內部的流程建模和執行監控。有了以上內容後可以看到，對於上述介面都需要進行服務化，不管是招投標模組本身提供的服務還是其需要呼叫和消費的服務。在該過程中就存在一個現實問題，即：
其它已有業務系統是否會配合進行服務化的改造？
如果其它系統很難配合，那麼在微服務模組的遷移過程中就存在要單獨實現一個服務代理模組，由該模組來實現介面的服務化工作，該服務代理模組本身還可以實現統一服務目錄庫的工作。在企業整個微服務架構逐步成型後可以看到該服務代理模組能力會最終融入到微服務閘道器和總線上。
其次，需要考慮介面服務實時呼叫
在服務實現上需要考慮的一個關鍵問題就是我們透過服務呼叫消費的資料儘量不落地，即實時的透過服務同步查詢外圍共享資料，包括專案資訊，供應商，人員等基礎資訊。而在招投標內部的表中也僅僅儲存外來鍵ID，減少對重複資料的冗餘。而對於我們需要分發的資料則儘量是透過訊息中介軟體機制實現非同步分發，減少耦合。
由於資料不落地會導致我們在招投標模組前端實現過程中存在多次資料查詢後組合，這是不可避免的問題。當然你也可以在招投標模組中增加一個領域服務層來實現類似組合服務的功能。
私有資料庫設計-資料庫拆分
這些都考慮清楚後需要考慮私有資料庫的設計，注意在微服務模組剝離過程中，招投標模組本身需要對應一個獨立的私有資料庫，可以是SID資料庫例項級別，也可以是Schema級別。當採用Schema級別的時候務必注意不能使用跨Schema的關聯資料庫表查詢語句，否則在資料庫層面仍然是緊耦合。在資料庫剝離後可以看到，對於招投標模組本身內部業務功能到私有資料庫可以採用內部API方式進行呼叫，但是對於外部的資料和業務協同只能透過釋出的服務進行呼叫和整合。
底層雖然進行了微服務和模組化改造，但是使用者最終關心的仍然是完整的業務系統和功能，因此在微服務模組剝離後需要考慮的就是整體外層門戶框架的單點整合能力。對於單點整合方案已經有很多標準的實現方式，在此不再進行詳細描述。
在任何一個微服務模組的改造過程中，仍然涉及到底層平臺層能力如何解決的問題。
拿上面的場景來說，原有的採購管理系統裡面可能已有有完整的流程引擎能力，那麼剝離的招投標模組是否採用該流程引擎？還是說在微服務模組的改造過程中將核心的平臺層能力也逐步剝離出來，如將流程引擎能力也剝離出來形成獨立的共享流程平臺。這些都是我們需要考慮的問題。
個人建議的方式仍然是伴隨著微服務模組的遷出同時，將可共享的核心平臺層能力也同步剝離，形成底層共享技術服務能力平臺。
一個微服務模組沒有和Docker整合並不代表不是一個完整的微服務架構，一個微服務架構的核心判斷標準仍然是元件化和服務化，資料庫的單獨剝離。上述的這些問題考慮清楚後，接著才考慮該微服務模組內部的技術架構和服務實現方式等問題。
在單個微服務模組的實現中仍然推薦採用類似OSGI匯流排來實現內部的整合，在該模式下元件本身的動態部署和擴充套件能力將剛強。也更加容易在後期將內部的API釋出為外部可以消費的服務。對於前期對開源ESB的研究可以看到，類似Karaf這種基於OSGI的框架可以是一個備選方案。
微服務模組在遷出地過程中應該儘量減少對已有業務系統的影響，減少對使用者使用層面的影響。即任何業務系統架構改造和內部的複雜性都應該遮蔽在內部。
在上述整體思路清晰後，剩餘的即是關鍵技術問題的解決，包括了分散式事務，介面安全和效能，動態部署，彈性擴充套件，模組健康監控，DevOps能力等，這些在整個實施過程中都必須逐個考慮和解決。要清楚一個遺留的系統在進行微服務架構改造中，前期是增加了複雜度，特別是前期的解耦和後期的整合。微服務架構改造真正受益的是在後期的運維管控和平臺彈性擴充套件上。
對資料庫和功能拆分進一步說明
還是以招投標系統準備單純拆分出一個微服務進行建設的思路來說明如何對已有的一個遺留系統將某一個獨立功能拆分拆分出來構建微服務。
在確認了招投標模組需單獨拆分出來構建微服務的時候，實際上對於哪些業務功能需要拆分出來直接對應到原來的大系統的招投標管理一級選單進行拆分出來即可。
比如上圖舉例，對應FUN打頭的為需拆分出來的功能模組，對應EXT打頭的為採購系統其他的業務功能模組。那麼在功能模組列出後，最簡單的仍然是進行CRUD分析來快速的梳理和確認哪些資料庫表要進行剝離到獨立的招投標資料庫。
經過上面圖分析可以看到三種情況。
情況1：CUD操作，這類一般來講對應的資料庫表都需要剝離出來。情況2：FUN對錶有更新操作，這種一般說明招投標模組對採購其他模組表有更新，存在介面。情況3：EXT功能對招投標的表有R操作，說明微服務拆分出來後仍然需要開放介面如何排查具體的CRUD操作？
在基本思路搞清楚後，還需要看下如何具體的排查CRUD操作。
做過開發的可能比較清楚，要排除相關的CRUD操作並不是一件容易的事情。還是拿招投標模組剝離來舉例。對應招投標業務功能我們可以明確剝離，具體涉及到哪個專案，哪些具體的程式碼檔案。在這塊剝離後我們需要做如下方面的工作來逐一分析存在哪些資料庫操作點或外部整合點。
僅分析當前招投標對應的程式碼檔案本身的資料庫CRUD操作，這塊把整個專案對應的招投標部分程式碼全部拿出來，逐一排查資料訪問層，基本可以快速的確定。即前面談到的FUN部分對資料庫表之間的CRUD關係資訊。
其次，這部分專案本身還可能呼叫了採購訂單模組的功能進行相關操作，比如呼叫了訂單模組的Order類中的UpdateOrderStatus方法。那麼這些點就需要單獨列出來，作為具體的介面改造點。
再次，是否存在檢視的情況，如果存在檢視的情況還需要分析在招投標模組用到的檢視是否存在關聯了非招投標模組的資料庫表的情況，如果有這種情況那麼也需要單獨列出，即在資料庫表拆分後這種操作不再支援，需要在上層透過程式碼區實現組合。
遺留架構遷移-中臺和服務代理傳統企業轉型微服務架構，實際上我們思考最多的就是如何進行平滑遷移和逐步過渡，如何在轉向微服務架構的過程中對已有的遺留業務系統影響最小，並對已有的遺留系統逐步進行平滑遷移。
在原來的多篇文章中，實際上我提出的思路都是會涉及到對已有系統進行重構，這個一方面是底層資料庫的重構，也包括上層的微服務模組化和介面服務化重構，但是這種重構本身一定會對業務系統造成一定的影響。而今天這篇文章談的重點是：
將微服務架構思路應用到我們新的業務應用構建中，對於老系統先保留現狀，而在新業務應用構建過程中一定涉及到需要使用已有業務系統的業務能力和資料能力提供。
為了達到這點，提出不碰觸已有業務系統邏輯層實現，全新建設中臺各個微服務模組中心的思路，在建立這些中心的時候可以先不去觸碰底層的資料庫，而是基於已有的資料庫來構建上層的各個中心。
各個中心就是我們說的業務或資料能力提供中心，各個中心完全微服務模組化，內部也包含業務規則和邏輯的實現，這部分和已有業務系統的邏輯層部分內容是重複的，但是不要緊。可以理解為已有業務系統的邏輯層邏輯在重新梳理和解耦後，遷移到新的中臺層的各個微服務中心中。
各個微服務中心直接和已有業務系統的底層資料庫打交道，而不是和已有業務系統提供的WS服務或邏輯層API打交道，這樣做的目的是儘量減少多層WS服務呼叫帶來的分散式事務處理問題。
在構建微服務中心的時候，這個時候就不再是單純的原子服務提供，也包括了組合服務能力提供，即各個微服務中心能夠提供領域層服務能力。這個組合服務在實現的時候可能需要訪問底層多個數據庫，但是對於前端應用來說並不關係，對於底層實現邏輯對上層透明。
這種思路重點就是首先考慮中臺能力的微服務模組化，同時將已有業務系統的邏輯層能力進行遷移，然後最終轉化為API能力介面朝上層暴露。這些能力介面可以用於構建新的業務應用使用。比如我們說的，當構建一個新的業務應用的時候，如果傳統方式下面需要和底層的PMS，SCM，ERP，EAM等多個業務系統打交道和協同，而新的業務應用構建模式就變成了，只需要和中臺的API閘道器暴露的服務介面打交道即可。
而中臺各個模組的API介面能力的實現本身是包含了業務規則的，包含了能力組合的，這些不是單純的代理回原來的業務系統邏輯層，而是重新實現了一遍，是原有業務系統邏輯層能力的遷移。這種遷移雖然導致業務規則邏輯有兩套，但是也為傳統業務系統最終的微服務化打下了堅實的基礎。
即提供API能力的中臺服務層構建完成後，可以看到對傳統的業務系統進行重構也很簡單的了。即傳統的業務系統原有的邏輯層能力大部分已經完成了遷移，我們需要做的僅僅是對前端展現層和能力組合協同部分進行重構和遷移即可。
其次我們看到這種方式下，在資料庫後續進一步拆分情況下，我們提供的服務介面本身是不需要進行變更的，即上層的業務應用不需要變更，這個時候只需要對服務實現邏輯進行調整介面。這種解耦本身是相對有必要，原因就是我們在傳統架構朝微服務架構轉移的時候，並不一定一開始就要考慮資料庫層的垂直拆分。
所有中臺的各個中心都按微服務架構模式單獨設計實現，單獨補充並提供介面能力，最終API介面統一註冊到API閘道器朝上層或外部統一提供。也就是說各個中心之間本身松耦合，同時各個微服務中心和已有的各個遺留業務系統之間本身也是一種松耦合的關係。
遺留架構遷移-構建中臺能力服務層在前面有一篇部落格文章我曾經談到過，透過服務代理的方式來構建企業中臺能力服務層，今天基於這篇文章的思路進一步細化整理，同時對構圖進行了重新調整。
中臺能力適配的三種方式
如上面圖所示，在構建新的中臺能力服務層的時候，為了對已有的業務系統影響最小，我們需要重新構建中臺能力介面，這個介面涉及到一定的適配和定製開發工作量。具體介面的實現本身又包括了三種方式，這個在前面一篇部落格文章也談到過，即：
1. 直接連線遺留系統的資料庫，來重新開發介面服務。2. 透過遺留系統已有的JAR包引入，來重新開發介面服務。3. 透過遺留系統已有的WS或Rest等介面服務適配，來重新開發介面服務。可以看到三種模式中對於資料庫這種模式是對業務系統依賴最小的模式，但是這個模式本身也是需要我們重新大量完整性校驗，業務規則的模式。這種模式本身就可以看到對遺留業務系統的部分業務規則和能力進行了重寫，即這部分業務邏輯規則已經在朝中臺能力層逐步遷移。
這種遷移形成的介面服務能力，一方面是構建全新的業務應用可以使用。而同時，我們建議是及時對於PMS或SCM等業務系統，如果有全新的業務模組需要開發，也完全可以基於中臺已有的介面服務能力進行，只有這樣才容易實現後續的業務系統逐步遷移到中臺架構上。
資料重構和服務組合是中臺另外一個關鍵能力
在中臺能力構建的時候，一定要考慮資料重構和能力組合，即中臺的能力介面不是簡單的資料庫CRUD能力暴露，也不是已有的遺留介面的簡單適配和代理接入。而是真正根據業務流程和業務需求驅動，失敗關鍵的業務能力，將業務能力轉變為服務。這種服務本身是粗粒度的，有明確的業務含義，有點類似我們在領域架構設計裡面經常談到的領域服務能力。
領域服務本身統一，有提供領域資料物件的資料類服務，也有提供業務邏輯和規則處理的業務類服務，這些都是領域服務能力。在前期中臺構建的時候我們看到資料類服務相對容易構建，但是業務類服務本身較難，因為遺留系統已經實現的業務處理規則和邏輯在程式碼裡面，如果我們用資料庫適配模式很容易遺漏已有的業務規則實現。
因此在前期中臺服務能力構建的時候，建議還是先以查詢能力服務能力開放為主來構建。當然我們也可以提供一些基礎的領域物件匯入服務能力，這種匯入服務提供一些基礎的資料完整性校驗能力，形成業務系統的單據草稿。而實際的業務單據規則處理和流程仍然還是在遺留業務系統中。
服務組合是中臺存在的另外一個關鍵價值，即我們可以根據業務需求一次返回組合後的領域物件資料，這個領域物件可以是多層結構，可以一次返回。這個領域物件也可能是涉及到多個數據庫表間的關聯。如果多個數據庫表是跨物理資料庫的。我們可以
1. 在中臺能力實現的時候，呼叫多次底層原子服務返回多個數據集物件。2. 在中臺實現的時候對多個數據集物件進行資料重構和組合，並返回組合後的領域物件給消費方。中臺層對介面服務進行標準化和規範化
中臺層在介面服務實現的時候，最好在適配的過程中對對介面服務進行標準化和規範化，即提供標準的WS或Rest介面服務能力，服務預先制定的服務契約或規範要求，同時符合日誌審計，安全管控要求。
中臺層的標準WS介面服務最後統一註冊和接入到API閘道器，這樣API閘道器本身能夠更加輕量，不需要做太多的適配，資料對映，轉換等工作。而重點是實現服務代理和統一服務目錄提供，負載均衡，日誌審計，安全能力，流量控制能力即可。
即這種模式類似於構建了一個厚中臺+輕API閘道器的模式。
透過中臺能力層處理業務轉換和服務編排
對於中臺中心，還有一個很重要的作用就是介面規則和邏輯轉換中心，資料轉換和對映中心，即對於源系統和目標系統間可能存在一個介面資料互動，但是要實現這種介面互動需要對資料進行相關的資料清理轉換，資料對映，業務規則邏輯校驗後才能夠進行，而對於源系統本身不清楚目標系統的業務很難來實現這些規則，而目標系統本身又不太想去做這些標準介面外的轉換清理工作，那麼這個時候可以由中臺來完成。
這個時候中臺的作用有點類似於資料交換平臺，也類似於處理採集和處理中心，也類似於我們原來用ESB匯流排的時候用到的BPEL服務能力編排。即出現如下場景的時候我們可以考慮由中臺來承載。
1. 對於需要資料互動和協同的兩個系統間有業務鴻溝，相互之間不是一套業務體系或標準。2. 對於資料整合中需要對資料進行完整性校驗，業務規則邏輯處理場景。3. 對於資料整合過程中，需要呼叫外部服務進行業務規則邏輯判斷。4. 對於一個業務需要進行資料加工，如組合多類資料形成一個完整的資料包再進行資料整合和推送。資料處理轉換和業務邏輯處理
當出現以上這些場景的時候我們可以考慮用中臺來解決。
我們舉個例子，在我們一個財務中臺的專案建設和實施案例中可以看到，使用者的報賬申請單在OA系統裡面填寫，即形成報賬申請單，但是財務系統關係的是最終的應付憑證，而將報賬申請單轉換為財務要求格式的應付憑證，中間就涉及到資料對映轉換，資料豐富，業務規則邏輯處理等操作。而這些操作就可以在我們構建的財務中臺來完成，這樣對於OA系統和財務系統本身都達到改造工作量最小的程度。
另外一個就是我們常看到的服務組合編排場景
比如在採購訂單匯入的過程中，需要呼叫預算系統提供的介面服務對預算進行扣減，但是如果匯入過程中出現失敗或異常，我們又需要對扣減的預算再次呼叫介面進行回補或釋放。在整個過程中這種操作邏輯就可以在財務中臺實現。即類似使用原來的BPEL來實現多個服務的編排操作。
也可以看到，在當前中臺和微服務架構下，對於原來的ESB服務匯流排已經變成了輕量的微服務或API服務閘道器，而ESB匯流排已有的比較重的資料轉換，對映，資料校驗，資料豐富，業務規則處理，外部介面服務呼叫和服務編排等能力都不再保留。因此這些能力需要找一個繼續承載的點，而中臺層就是一個比較好的繼續承載這些能力的地方。這樣也方便原有IT架構更加平滑的朝中臺架構遷移。
基於DevOps和容器雲部署
對於企業的中臺能力服務層，完全可以採用微服務架構和容器化技術進行建設。其中我們可以進行中臺各個中心的規劃，對於每個中臺中心就是一個獨立的微服務模組，可以進行完全獨立自治的設計開發和後期運維管理。
每個微服務模組進行獨立部署，可以與容器雲平臺結合，透過容器資源池來實現計算節點的動態擴充套件能力。同時對於動態擴充套件的計算節點在上層進行負載均衡，提供統一的IP地址出口。該層的負載均衡能力需要和容器資源池動態擴充套件自動結合，因此需要實現微服務框架和容器平臺Kubernates資源排程層的融合能力。
在類似使用者中心，專案中心，訂單中心等原子服務中心上層，還需要構建領域組合服務中心，實現原子服務的能力組合。該組合能力提供需要呼叫原子中心的各個原子服務能力。注意，由於組合服務本身存在分散式事務的問題，因此需要考慮對於前期組合類服務的提供，最好以查詢組合類服務介面為主，對於查詢類組合服務出現服務異常一般不存在具體回退的問題。
中臺各個服務中心將其負載均衡後的服務地址再次接入到上層的API服務閘道器中，透過API閘道器提供統一的服務目錄庫地址，同時透過API閘道器來實現安全，日誌，流量控制，服務代理等關鍵能力。
由於當前中臺服務能力中心的構建以代理適配模式為主，即資料來源頭仍然是已有的遺留系統的各個資料庫，因此對於中臺能力中心實際上不需要有自己的Ower資料庫，僅僅是業務邏輯層的服務部署包。除非出現傳統業務系統所有業務功能遷移到中臺的情況，才涉及到需要重新規劃中臺模組對應的資料庫。
在中臺能力服務層構建的時候，可以採用我們提供的DevOps支撐平臺，該支撐平臺提供對容器化資源池，部署流水線，微服務架構，API服務閘道器等整體打包解決能力。可以進一步實現中臺能力層的快速開發和交付上線。對於DevOps支撐平臺的介紹可以參考我前面發過的文章。