雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
本篇文章分享了關於企業數字化，傳統企業IT架構轉型方面的一些思考。
做互聯網，企業信息化和IT系統建設，企業數字化轉型相關工作的可能都知道，最近幾年對於中臺，微服務，雲原生，消費互聯和產業互聯，DevOps和雲原生解決方案等相當的火爆。
那麼對於已經進行了傳統方式信息化建設的企業，企業的CIO和信息化經理估計時刻都在思考類似遺留IT系統如何轉型？如何應用這些新技術？使用這些新技術究竟能夠帶來多大價值等一系列的問題。頗有點當年不上ERP等死，上ERP找死的味道。
對於我自己從事企業信息化建設工作多年，特別是最近幾年也接觸了大量的企業IT部門，在經過這幾年的外部項目建設，客戶IT建設諮詢相關問題溝通後，更加讓我明確了對於大部分企業來說IT架構轉型，新架構建設並非易事，盲目跟風往往更是帶來後期大量IT管控治理問題。
業務目標驅動而非技術驅動
對於任何一個企業的信息化建設，簡單來說就是業務目標驅動而非技術驅動。對於業務目標驅動我們又可以理解爲在最高效的支撐業務目標的同時實現最好的投入產出比。
你所在企業的核心競爭力是什麼？
任何一個企業核心競爭力一定來源於企業價值鏈分析模型中的核心價值鏈。可以是價值鏈中的一個流程，也可以是一個關鍵指標，而不是你的支撐過程能力。
核心競爭力可以是產品或服務可高度定製化，可以是性能指標最優，也可以是產品同樣質量條件下價格更低，性價比更優。這些纔是企業能夠長期經營和持續發展的核心價值所在。
我們經常看到一個企業花很多錢，請國外的諮詢公司做信息化規劃諮詢，雖然方法論很科學，模型和文檔輸出也很完善，裏面可能還附加了很多業界標杆和最佳實踐，但是企業很難按照這個去做，或者說按諮詢建議做了也沒有得到很好的效果。
那麼實際問題在哪裏呢？
我並不是說方法論不重要，而是大部分企業的信息化建設根本就沒有到需要這麼重的方法論來指導的地步，其次在當前信息化發展快速情況下沒有任何一個諮詢機構能夠保證自己規劃的東西5年後還適用，那麼你去做5年後的規劃有何意義？
因此很簡單來說，在你理解了企業核心業務競爭力後，你剛開始的IT系統建設一定是圍繞這些競爭力實現服務的，即使投入再大，建設複雜度再大你也要努力分階段去建設和實現。
我們常說的信息系統建設決策中的複雜度，成本投入等指標全部不適用。比如你核心是產品質量和性能指標參數，那麼你上MES系統優先級往往是最高的。雖然MES系統建設的難度，週期，複雜度都很大，但是你也必須迎難而上。
企業IT部門不能花點小錢上了OA或HR就沾沾自喜，雖然說上了OA對自動化和效率有幫助，但是對企業核心業務目標和競爭力提升沒太大作用。
IT如何支撐核心業務能力？
對於IT系統如何支撐企業核心業務能力實現，簡單來說就是當前的業務能夠完全自動化支撐，業務流程連貫斷點，業務數據一致無差錯，業務系統易用速度快，業務數據能支撐持續改進。
從業務的視角可以看到，業務的述求裏面從來就沒有一條技術多先進，架構多靈活。
因此IT系統的建設和架構選型最終要以匹配業務目標出發，去選擇在當前架構下最合適的架構方案。這個架構方案是性能和高可用，成本投入，可持續運維多方面的一個均衡。
大家要注意不是說架構可擴展性不重要，傳統架構同樣具備擴展能力，不是說你必須要上了中臺和微服務架構才能夠擴展。這些我們一定要有清晰的認識。
外購自主產品還是自主研發？
業務驅動裏面強調了兩個點，一個是業務價值實現，一個是IT投入產出最大化。
在我們考慮IT建設是外購還是自主研發，包括對於外購是按我們要求定製開發還是按供應商產品標準實現等問題的時候。核心需要考慮的就是在滿足業務目標的時候如何實現最好性價比。
如何看IT投入性價比？
任何一個事情不能以短週期和靜態的視角，而是應該以動態和長週期的視角。
拿IT系統建設舉例，外購一個系統包括了前期產品購買+實施費用+後期運維費用；而自主研發則全面是人員投入費用。那你就需要用一個3到5年的週期去比較究竟哪個更划算。
IT系統建設說了這麼多年，包括最近幾年大量傳統IT系統也逐步變化爲SaaS服務模式，對於企業CIO來說要清楚的是你不要糾結你建設了數據中心，有套自己的軟件系統，這些本身沒有任何價值。
IT系統本身無價值，而是IT系統提供的IT服務能力產生價值，是IT服務在支撐了業務運作後遺留下來的數據本身有價值。
軟件即服務，你需要的是服務，不是軟件本身。
正是由於這個原因，對於大部分企業來說都是採購標準產品優於自己建設，採購雲服務由於標準產品，當然這個選擇的前提仍然是支撐業務目標要求的前提下。
對於現在企業內部的CIO或IT管理人員，我們看到一個奇怪的現象，就是啥技術熱上啥，能夠自研一定不購買成熟產品，把公司的IT團隊搞得越來越大，招兵買馬拉山頭，技術也越來越複雜。這反而是一種極其不負責任的做法，即IT部門或管理者間接綁架了企業，企業確實離不開IT了，但是IT究竟爲企業帶來多大的業務價值，每年大量的IT投入究竟值得不值得說不清楚。
企業優秀CIO一定是對已有IT資源和成熟產品整合來支撐核心業務的能力。而不是去形成一個先進技術架構，核心技術研發團隊的能力。
中臺和微服務-從產生背景說起
對於中臺概念，大家都比較清楚是阿里最早提出了大中臺，小前臺的說法。阿里巴巴 “大中臺、小前臺”機制的提出，某種程度上是從傳統的事業部制向準事業部制的轉換。
對於中臺核心價值可以總結爲關鍵的兩點，第一點就是靈活敏捷支撐業務。
就阿里巴巴而言，“前臺”就是貼近最終用戶/商家的業務部門，包括零售電商、廣告業務、雲計算、物流以及其它創新業務等；而“中臺”則是強調資源整合、能力沉澱的平臺體系，爲“前臺”的業務開展提供底層的技術、數據等資源和能力的支持，中臺將集合整個集團的運營數據能力、產品技術能力，對各前臺業務形成強力支撐。
前臺和中臺本質上是工作分工的問題。比如，某部門要開發一款App，是部門內部（大前臺）自己組織一套技術、產品、設計、運營的團隊，還是集團爲其提供資源（大中臺），由專門的技術團隊來幫助其開發、設計產品等等。
所以說， “小前臺，大中臺”的運營模式，就是美軍的“特種部隊（小前臺），航母艦羣（大中臺）”的組織結構方式，以促進管理更加扁平化。十幾人甚至幾人組成的特種部隊在戰場一線，可以根據實際情況迅速決策，並引導精準打擊。而精準打擊的導彈往往是從航母艦羣上發射而出，後方會提供強大的偵察火力後勤支援。所以如果中臺沒有辦法承接前線的需求，前線就會不認可它服務的價值。
第二點就是通過中臺來實現進一步的資源整合複用，降低成本。
阿里巴巴近年來迅速擴張、員工衆多，所以可能會存在管理不善、效率低下、各事業部各自爲政等問題。爲了解決以上問題，阿里提出了“大中臺，小前臺”機制。“小前臺 大中臺”的運營模式促使組織管理更加扁平化，使得管理更加高效，組織運作效率提高，業務更加敏捷靈活。
其“中臺”的設置就是爲了提煉各個業務條線的共性需求，並將這些打造成組件化的資源包，然後以接口的形式提供給前臺各業務部門使用，可以使產品在更新迭代、創新拓展的過程中研發更靈活、業務更敏捷，最大限度地減少“重複造輪子”的KPI項目。前臺要做什麼業務，需要什麼資源可以直接同公共服務部要。
大家看到這兩點，是否覺得跟傳統企業內部信息化建設經常說到的SOA架構思想很類似。我們可以來看下SOA本身的定義，即：
SOA是一種架構方法，將傳統的單片式應用打破，分解爲離散的、自治的業務服務，利用標準提升他們的互操作性，從而可以更好地共享、重用和組裝，快速構建複合的應用從而滿足業務需求的變化。
在面對企業遺留IT系統架構的時候，SOA本身實際也是做兩個重要的事情，其一是找到各個遺留系統共性的可複用的業務能力；其次就是在構建上層業務流程的時候通過服務組裝和編排來完成。這個思想和中臺思想完全一致。
只是大部分企業將SOA簡單理解爲了ESB和集成平臺，更多用SOA去解決集成的問題，而忘記了SOA架構思想的本質仍然是共性業務能力下降，上層應用靈活編排。
再次說明，現在有個主流說法SOA已經過時，這個說法明顯是不合理的，SOA僅是架構思想，這個架構思想不會過時，只是實現SOA架構裏面的ESB可能逐步過時被API網關或ServiceMesh架構替代。
接着再來看下微服務，談微服務一定是和單體應用對比。
微服務架構強調的第一個重點就是業務系統需要徹底的組件化和服務化，原有的單個業務系統會拆分爲多個可以獨立開發，設計，運行和運維的小應用。這些小應用之間通過服務完成交互和集成。每個小應用從前端web ui，到控制層，邏輯層，數據庫訪問，數據庫都完全是獨立的一套。
在這裏我們不用組件而用小應用這個詞更加合適，每個小應用除了完成自身本身的業務功能外，重點就是還需要消費外部其它應用暴露的服務，同時自身也將自身的能力朝外部發布爲服務。
如果一句話來談SOA和微服務的區別，即微服務不再強調傳統SOA架構裏面比較重的ESB企業服務總線，同時SOA的思想進入到單個業務系統內部實現真正的組件化。
我們可以先看下從單體應用到微服務架構的變化圖。
從上面圖裏面我們可以清楚的看到單體轉到微服務後帶來的兩個核心差異：
- 一個單體變多個微服務模塊，而且從數據庫到邏輯層到前端完全獨立
- 微服務模塊間通過Http Rest接口高效集成協同
談到這裏，我需要糾正下我原來的一個看法。
即SOA和微服務本質上不應該放在一個層面去比較，因爲SOA裏面強調的橫向分層，可複用服務積累，上層服務靈活組裝形成應用幾個關鍵點在微服務裏面都沒有。微服務僅僅是模塊間接口交互走了輕量的Http Rest接口而已。
微服務簡單來說強調的是縱向大單體拆分小，因此更多應該和單體應用做對比。
題外話：經常看到有人將業務邏輯層理解爲中颱，這個也是錯誤對比，這兩個不是一個層面的概念。中臺模塊有業務邏輯層，前臺模塊也有。要明白不是所有業務邏輯都是共性和可複用的，對於不可複用的業務邏輯仍然是在前臺模塊中，而非中臺。
互聯網和傳統企業差異
對於中臺和微服務，我們看到互聯網企業建設案例特別多，在互聯網企業取得成功後很多傳統企業希望按照互聯網企業的做法來實施中臺和微服務，那麼我們就來看下實際的一些區別點。
IT本身就是互聯網企業核心競爭力
前面我已經談到，任何企業都要先分析其核心競爭力。
那麼對於一個建設和運營電商平臺的互聯網企業，它的核心企業本身就是這個電商平臺應用，而且你也可以看到研發，運維，運營等大量人力資源全部集中在這個平臺上。也就是說你看到的互聯網企業80%乃至更高的成本投入全部在IT建設和IT人員上面。
互聯網企業的IT系統或運營的APP就是其核心競爭力。
在這種情況下，互聯網企業捨得在IT上投入，因爲這個投入本身就是提升核心競爭力的，其次捨得招人自主研發，即IT系統的能力必須要牢牢的控制在自己身上，形成自己核心資產。
對於傳統企業來說，雖然IT也很重要，但是很少會說IT能力是企業核心競爭力。包括我們看到很多營收上10億的傳統企業一年不到100萬的IT建設投入都是常事。
所以從這點上來說，任何傳統企業都不可能投入大量成本來搞IT新技術。
傳統企業IT是否面對互聯網一樣的高可用需求？
對於互聯網企業，爲何對架構的性能，穩定性，擴展性等如此重視。簡單來說同樣也是運營的業務驅動。一個互聯網企業運營的平臺宕機10分鐘往往都是致命的，包括類似雙11，秒殺等各種活動，你必須要有高性能，高可靠和可擴展的架構來支撐。
否則流失的就是最終用戶和流量，最終影響到企業的運營和收益。
傳統企業的內部IT，即使併發量再大，很少有需要達到互聯網這種大併發量的需求；即使高可靠性要求再高，也很少說需要做到完全沒有停機運維時間。
殺雞焉用牛刀，而很多傳統企業往往搞得就是老想着用新架構和新技術來解決手裏面的問題，而不是想着如何把自己手裏面的菜單磨得更快。
3年左右擴展需求是必須考慮，什麼爲5到10年擴展需求考慮就是扯蛋。
再來理解傳統架構到中臺微服務的變化點
前面介紹了中臺和微服務的基本思想。
可以看到對於傳統架構轉型過程中，剛好就是中臺和微服務兩者思想的一個融合過程。中臺強調的是橫向分層和能力共享，而微服務強調的單體縱向拆分更細。如下圖：
在談中臺的時候更多的是業務層面用詞，而談微服務的時候更多是技術層面用詞。在談中臺的時候你首先考慮的是業務模塊如何劃分，服務如何識別，而實現技術是微服務。而談微服務的時候本身就是技術實現和架構方法，是否一定用於中臺倒不是必須。
因此要回答兩者區別這個問題，我們首先還是要看下中臺和微服務這兩個概念是針對什麼來說的。
- 中臺：說中臺一定會說到前臺，原來是中臺前臺不分，現在是拆分爲中颱和前臺。
- 微服務：說微服務一定說單體應用，原來應用粒度太大，要垂直拆爲更小的微服務。
這個搞清楚後，我們就更加容易理解兩個概念的區別，即：
中臺更多的是指橫向拆分，即共性業務能力的下沉，然後再將服務能力開放給前臺應用使用。而微服務更多是技術用詞和軟件架構開發方法，強調的是大單體要拆分和進一步解耦。
而我們現在構建企業中臺，基本是中臺和微服務都會使用到，即既需要進行橫向拆分，共性能力下沉。同時對於下沉的共性能力又需要按微服務思想進一步拆分多個微服務模塊。在中臺思想裏面更加強調了共性能力下沉和能力開放，能力開放以微服務裏面常見的輕量API接口方式進行。
瞭解了這個我們看區別就比較清楚了，具體如下：
中臺強調橫向拆分和分層，微服務強調縱向拆分和解耦。
中臺建設的目標更多的是下沉共性能力，識別和暴露可複用的API能力接口，供前臺應用快速開發和組合，這纔是中臺構建的目的。而對於微服務來說，更多強調的是單體應用進一步的拆分和解耦，並通過輕量API接口高效協同，只要滿足這個要求本身就是微服務思想實現。
中臺的構建不一定要採用微服務，也可以採用傳統IT架構進行構建，只要滿足共性業務能力下沉要求即可。類似我們傳統架構裏面的MDM主數據系統，按現在微服務思想應該拆分多個服務，但是即使沒拆，我們仍然可以理解爲是企業中臺建設思路。
再次強調中臺和微服務區別的一個原因就是。
當企業重點是在構建可複用的業務中臺能力的時候，你完全不必一定按互聯網做法將中臺拆分爲多個微服務，即使沒有拆分，只要你識別了共性可複用的業務服務，並統一暴露給上層業務使用，那麼就可以理解爲企業進行了中臺建設。
比如企業已經建設了ERP，CRM，PLM，SCM等多個業務系統。現在將各個業務系統共性業務服務能力識別出來，並開發後註冊接入到ESB平臺形成統一服務能力開放。在企業構建新的報賬業務的時候剛好可以複用這些已有能力，那麼這個共性能力積累就可以看作是企業中臺。
新架構引入應以問題和風險驅動
在我們談IT架構轉型的時候，一定要從實際的場景和問題去分析，不是爲了新架構而架構，這個也是我一直強調的重要觀點。而對於問題本身我們又要理解到實際上包括了兩點。
- 當前已經面臨的問題：類似系統性能問題，運維問題，安全問題等。
- 已經發現趨勢的風險：根據歷史數據趨勢已經發現關鍵風險。
當前已經面臨的問題
對於一個傳統的IT應用架構，我們可以來看下可能存在的當前面臨的問題，這些問題既包括了業務層面，也包括技術層面，還包括了管控治理層面。但是最終都可以歸集爲對於IT系統支撐業務需求和業務目標的能力變弱，或者說已經到了無法支撐的程度。
其一，老技術框架已經無技術支持
一個IT系統的開發一定會涉及到相關的技術架構選擇，包括了技術平臺，開發框架，開發語言，開源組件使用等，而這些平臺或框架隨着時間推移本身也在不斷升級，還有些乾脆就是不再提供技術支持。這些都需要我們對已有的IT系統進行全新改造或升級。
類似我們原來用VC++開發的業務系統，到了11年都還在用，但是微軟已經不提供支持，只能夠逐步將功能移出。還有就是開發框架和語言，數據庫的版本在不斷升級，舊版本不再提供支持，這些也需要我們定期對業務系統進行版本升級改造。
其二：應用以及無法再進行擴展
傳統IT系統是單體應用，雖然單體應用本身可以集羣化部署，但是很多時候對於數據庫往往並不會使用RAC集羣，或者說數據庫本身並沒有擴展能力。這個在業務系統發展到後期，在用戶數，業務數據量，併發量都不斷增加的情況，帶來的明顯問題就是性能問題。
而這個性能問題也是業務系統不斷持續優化的關鍵，包括了數據庫集羣化升級改造，歷史數據清理和遷移，本身的SQL語句和代碼優化等各種方式，最終都是爲解決性能問題。當以上各種方式和努力都不太起作用的時候，往往就涉及到真正開始將單體應用進行逐步拆分和剝離。
其三，IT系統的可運維能力下降了
發現問題或故障的時候查找原因很難，可能大半天都定位不了具體的問題究竟出在哪？其次就是系統原始架構就部署完全冗餘化設計，導致出現問題後的系統恢復時間也變慢了，有時候即使重啓整個應用也無法恢復，這些都將直接影響到具體的用戶使用和需求滿足。
其四，單體系統模塊緊耦合導致敏捷響應業務需求的能力變慢了
用戶提交的需求變更往往要花很久的時間才能夠變更完成並最終上線發佈。其原因就是整個單體系統隨着後續功能的疊加變得越來越複雜，模塊間的耦合性也是越來越強，即使最簡單的一個變更可能都涉及到代碼多處的改動，而且代碼和代碼之間還有千絲萬縷關係，稍不注意就可能影響到其它能夠正常使用的代碼。還有些應用模塊間的集成還不是走的標準的應用層API接口，而是直接使用的數據庫Dblink連接，這個更加導致了一個數據庫究竟有多少外圍在使用，究竟使用了哪些數據庫表完全不清楚，任何一個數據庫的表結構變更往往都影響巨大。
已經發現趨勢的風險
什麼叫已經發現趨勢的風險，簡單來說就是隨着用戶數，業務量和併發量的增長，你已經能夠明顯感覺到系統在變慢，但是還能夠忍受，你預估和測算這個趨勢會發現到了哪個時間節點可能IT系統的能力就無法滿足。那麼你就必須提前去考慮這個問題，並對相關的架構和技術點進行優化改進，而不是眼睜睜的看着問題變化爲風險。
其一，系統可擴展性能力弱是最容易發現的風險
即隨時業務量增長你發現系統沒辦法做到完全的平滑擴展，這裏麪包括了數據庫，也可能包括了應用服務器集羣，你會發現由於沒辦法做到擴展，等數據量和併發量一上來一定會出現應用性能問題和瓶頸，這個時候你就要早點去考慮架構優化和升級。這個升級一樣兩個方式，一種是已有架構優化支持擴展性，一種就是徹底的微服務化拆分。
其二，IT運維能力無法有效支撐風險
就是前面說過的可運維能力變弱，IT系統上線了，但是你發現對IT系統的運維和監控能力沒有跟上，導致出現問題後查找和定位故障相對的耗費時間。那麼這種時候一定要考慮對系統進行優化，這個優化不僅僅是包括了實施相應的IT監控和APM系統，更加重要的是對已有的系統代碼進行優化，包括了相應的日誌記錄，日誌採集，性能數據收集等，關鍵異常日誌記錄等，這些都是方便你後續快速的定位故障和問題。
系統變得沒法維護了，也是我們經常會遇到的問題，代碼間耦合性強，而且邏輯混亂，修改代碼的時候往往摸不着頭腦，相關的變更也是到處亂加，到了這個時候一定要考慮對代碼進行優化和重構，理清代碼邏輯。所有開發人員都要意識到代碼的可維護性是代碼的一個關鍵非質量屬性。
傳統架構轉型必須思考三個層面內容
要說到傳統企業IT架構轉型，我們可以看到很多關鍵詞。
中臺，數據中臺，數字化，微服務，SOA，服務識別，API網關，DevOps，敏捷開發，持續集成，PaaS平臺和容器技術，中臺規劃，監控，運維，自動化測試，研發項目管理，過程改進，Spring Cloud框架，流水線編排等。
但是不論涉及到多少的技術和關鍵詞，我們可以看到傳統企業的IT架構轉型實際上核心就三點。分別是業務層，技術層面和管理層面。
- 業務層面：核心能力中臺構建，也可以說是微服務模塊的劃分和API接口服務識別
- 技術層面：核心是雲原生，包括微服務+DevOps+容器雲
- 管理層面：研發管理過程的改進和管控治理體系建設
其一，在業務層面重點是中臺建設規劃和服務識別
中臺建設的核心是基於企業架構+SOA融合思想，以業務驅動IT，從端到端業務流程出發，爲企業梳理完整的業務架構，數據架構，應用架構和技術架構，而整套企業架構規劃的方法也完全適用於粒度更細的微服務模塊劃分，中臺規劃建設。
當然新的中臺構建諮詢規劃對傳統企業架構也進行了大量裁剪和改進，在後面我會專門寫文章來進行說明，特別是在覈心的模塊拆分和服務識別上面。
其二，在技術層面重點是雲原生解決方案
對於Cloud Native翻譯爲雲原生，是Matt Stine提出的一個概念，它是一個思想的集合，包括DevOps、持續交付（Continuous Delivery）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據商業能力對公司進行重組。
雲原生應用程序開發通常包括DevOps，敏捷方法，微服務，雲平臺，Kubernetes和Docker等容器，以及持續交付，簡而言之，每種新的和現代的應用程序部署方法。
微服務架構+容器化+DevOps 將成爲後續企業信息化轉型的主流趨勢。而這三點剛好也是雲原生解決方案中最重要的內容。
簡單來說，一個企業實施微服務看着簡單，但是微服務一上來，原來的10個系統變成了100個模塊，這麼多模塊如何部署集成，如何管理，如何後期運維，這些都需要類似DevOps支撐和容器雲等一系列的技術相互配合才能夠完成。
其三，全面提升IT管控治理水平
這個就不展開講了，即新技術的實施你的管控治理能力也得跟上。從最早的軟件工程和研發過程管理，CMMI,到新架構下的敏捷方法論和持續集成等，這些都需要企業的IT部門逐步形成完整的，成熟的標準規範體系，並付諸於實踐。
包括我們當前看到的DevOps，也以及形成了完整的能力成熟度模型供實施企業參考。
因此對於一個企業，當你自身能力不足的時候務必謹慎對待微服務的引入。最後一個部分我想再次對這點做下詳細說明。
企業要謹慎對待微服務架構
以下談到的都是企業引入和實施微服務架構可能遇到的困難和阻力點，而實際實施難度可能遠高於我下面的描述。
引入的軟件開發商本身的水平和意願
如果一個企業本身IT部門規模小，軟件以外購爲主，那麼勢必在對ERP等各類軟件的選型評估後引入不同的軟件產品提供商或軟件開發商。那麼軟件商本身都有了成熟的產品或架構，其產品內部的模塊是否符合組件化和微服務架構的要求，我們不得而知。
即使招標要求寫明軟件提供商提供產品需要基於SOA或微服務參考架構，但是實際上由於企業本身的IT能力和水平往往也無法驗證，而對於軟件廠商來說一定希望是賣現有產品，減少改造和定製實現利潤的最大化。
對於軟件開發廠商來說對已有的軟件產品是沒有微服務架構改造的動力的。那在這種情況下要推動微服務架構實施落地必須的就是企業本身有很強的架構管控能力和甲方話語權。
比如甲方在有較強的IT規劃和架構設計能力情況下，纔可能一開始就劃分好微服務模塊並且設計好微服務模塊間的接口，再進行招標和選型。同時甲方話語權強的情況下，可以完全要求軟件供應商按照自己定義好的標準，規範，架構進行微服務模塊的開發。
簡單點來說頂層架構分解和接口設計能力不在單個微服務模塊開發商手裏面，而是在甲方手裏，或者在甲方請的專門負責規劃架構設計的技術諮詢團隊手裏。
在這種模式下，技術諮詢團隊應該對整體模塊劃分和後續集成負責，技術諮詢團隊就需要有業務和技術兩方面的能力，同時有類似領域的規劃設計經驗，系統開發建設經驗等。這些本身就對技術諮詢團隊提出了相當高的要求，可以來講很少有技術諮詢團隊達到這個水平，包括埃森哲或德勤等也難。
企業自有開發團隊實施微服務
如果企業本身的IT成熟度沒有達到一定階段，顯然是不可能推行實施微服務架構的。這個道理前面已經談到過，在企業IT建設中，如果連粗粒度的業務系統以及它們之間的集成都管理不好，那麼更沒有能力管理細粒度的微服務模塊。
那麼如果企業IT成熟度達到一定水平，在推廣微服務架構還存在的難點如下：
首先是架構設計能力的顯性化，即架構設計這個工作的輸入，輸出和過程需要更加的顯性化出來形成團隊都認同的標準工件。一個業務系統沒有拆分開時候，雖然有架構設計和組件劃分，但是這個工作是屬於團隊內部的事情，即使架構設計不合理，在後期集成也可以通過諸多變通方式解決掉。而現在是不同的微服務模塊可能分派到兩個獨立的團隊開發，原來屬於自己內部黑盒的問題變爲團隊間問題。
簡單來說你原來藏着或沒做規範的東西太多，而現在這些不能再藏着掖着了，當真要把這些東西拿出來的時候，你纔會發現你原來架構能力是有欠缺的。正如我們理解了一個東西，那麼要讓我們清楚的講出來困難，那麼我們的理解有欠缺。對於我們能講清楚的東西，要系統的寫下來有困難，那麼說明我們講的結構和條理有欠缺。
其次管控要求和規範體系的建立，對於管控要求可以看到如果兩個微服務模塊分給同一個團隊開發，如何才能保證開發的團隊保持兩個模塊的完全獨立和解耦，兩個模塊間不會出現相互交叉的數據庫直接調用，也不會存在直接繞開Service接口的其它耦合調用？這些如果沒有完整的管控和檢查體系我們很難約束。
微服務架構下導致的開發複雜度增加
只談微服務架構的松耦合和高擴展性，而不談開發和集成複雜度的都是耍流氓。
實際上當前很多企業對微服務架構並沒有如此迫切，互聯網很多企業推行微服務架構更多的還是考慮到巨大的業務併發量下的系統彈性擴展能力，而實際大多數企業內應用往往並沒有如此海量併發。
其次，即使在併發量增加的情況下通過進行代碼本身的優化，數據庫調優或者升級硬件服務器資源都可以較好的解決性能問題。而做這些事情投入的成本遠遠小於微服務架構帶來的開發複雜度增加成本，後期的運維管控成本。
要做到完全微服務模塊獨立，微服務架構下最大的一個變化就是數據庫也拆分開了，原來的一個業務系統如果分爲5個微服務模塊，那理論上就是5個獨立的後臺數據庫，而且數據庫間還不能隨便相互連接和訪問。只有這樣微服務模塊才能做到獨立部署和管理。
由於數據庫拆分帶來兩個問題，其一是我們原來很簡單的一個跨表查詢操作現在無法做了，我們必須調用兩個微服務模塊提供的服務，查詢到數據後再到邏輯層進行組合。其次最大的問題就是如果一個業務操作需要同時更新兩個微服務模塊的數據，由於服務本身無狀態，導致了這種分佈式事務問題很難解決。
企業內業務系統很大一個特點就是業務邏輯和規則相對互聯網更加複雜，而且有更高的事務一致性要求。正是由於這個原因，無法解決好分佈式事務的問題都將直接導致後續數據不一致和業務錯誤。
原來通過調用項目內一個API方法就能解決的問題，現在要調用遠程WS接口才能解決，這本身就增加了開發和調試的複雜度。一個微服務模塊與外部其它模塊的集成和協同越少，你會發現該微服務模塊和傳統業務系統開發沒太大區別，但是當其涉及到完成任何一個功能都需要調用外部微服務模塊的服務接口時候，其開發模式和效率上就會帶來巨大的變化。
微服務架構下導致的集成複雜度增加
任何一個微服務模塊在外部協同上都存在兩個點，一個是模塊本身要消費和調用其它微服務模塊提供的服務接口，另外一個是模塊本身又需要將其業務能力暴露爲服務接口給其它微服務模塊使用。
如果一個微服務模塊要同時支撐PC端和APP端，可以看到微服務模塊暴露的服務還需要統一提供給前端的展示用。那麼可以看到一個微服務模塊需要完成自身組件層和展現層間的集成，同時又需要完成多個微服務模塊組件間的橫向服務集成。
如果我們將消息，日誌，流程，4A等能力下層到平臺層微服務模塊，那麼一個組件要跑起來還涉及到和平臺層的多個技術類微服務模塊集成。在如此複雜的集成場景下，要將複雜的跨多個微服務模塊的橫向端到端業務跑通，其涉及到的模塊數，接口數都遠超原有單一系統的模式。
一個業務系統如果沒有拆分爲微服務模塊，那麼其它內的模塊間集成和集成測試是系統內部的事情，但是一旦拆分爲多個微服務模塊，那麼這種集成就變成外部第三方的事情，或者必須要顯性的事情。
對於一個微服務模塊來說，當其需要集成的外部微服務模塊和接口都變多的時候帶來什麼問題呢？這個問題大家容易理解，即該模塊究竟是否穩定已經不是模塊本身的事情了，而是涉及到諸多外部依賴模塊是否穩定。更簡單說本來原來我自己可以確認穩定的事情，現在我無法確認了。即使每個模塊的穩定度都90%，但是你會發現一集成起來90%90%90%，那麼穩定性就下降的很厲害。
正是由於這個原因，我們要求在一個大體系裏面，每個微服務模塊的開發質量都要得到保證，這已經不是單個模塊自己的事情，而是直接影響到大系統的質量。
微服務架構下的運維問題
在實施了微服務架構後，運維的複雜度也是成倍增加，任何一個微服務模塊出問題都可能影響到整個業務應用的功能使用。我們在運維時候不僅僅要健康單個微服務模塊，還需要健康所有的接口服務監控狀態。
如果跟Docker集成了，我們看到整個性能監控和問題分析都會變麻煩了，沒有實施微服務架構前發現問題，我們直接可以看應用服務器上類似Tomcat或jboss日誌，而實施了微服務架構後，應用容器已經是自動部署和動態分配的，原有的故障診斷模式行不通，而需要PaaS平臺本身提供完整的預警和日誌分析能力。
再次，如果發現了性能問題或故障，我們的解決方案是如何的？
我們如何保證不影響到業務運行，不出現數據的丟失，或者在微服務模塊擴展的時候不出現業務中斷等。這些已經不是簡單的部署架構層面的冗餘能解決的問題，而涉及到我們在整個微服務架構中的消息策略，事務管理機制，持久化機制等問題。
【雲棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/live立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK
原文發佈時間：2020-07-06
本文作者：何明璐
本文來自：“dockone”，瞭解相關信息可以關注“dockone”