近幾年，微服務和中臺的概念異常火爆，這陣風已經從互聯網公司，吹到了傳統企業信息化建設領域，幾乎在任何一個企業信息化建設相關論壇中都會涉及到。俗話說，外來的和尚好唸經，不少有數字化轉型訴求的傳統企業或機構組織，不管其領導人是否懂技術，都已經被或多或少地洗腦了。
但一方面，互聯網公司基於自身的業務特點持續迭代和演進出來的技術體系，是否適用於所有傳統企業？另一方面，傳統企業在模仿互聯網公司構建自己的信息化系統時，是否正確理解和落實了這些技術理念，還是僅僅照貓畫虎？
先說說微服務。
很多人認為，微服務的核心就是拆分。大功能太複雜，不好一次實現，但是拆分成一個個小功能後，每個小功能都單獨實現，這就簡單很多。此外，還可以將那些能夠為多個應用提供服務的通用性功能拆分出來獨立實現，以減少重複開發。
但是，沒有微服務概念之前，我們的系統就沒有拆分了嗎？舉例來說，有經驗的程序員都會將常用的代碼片段重構為公用函數；而在對象設計時，也都會將具有獨立業務意義的功能設計成一個獨立的類。
其實，微服務的核心理念是：只做一件事，並把它做到極致。而圍繞這一理念，微服務是有著管理層面和技術層面的兩種解讀方式的。
在管理層面，微服務通常是與企業組織架構相關聯的，組織架構中會形成不同的團隊去維護自己的微服務，這個團隊會對自己維護的業務更有歸屬感，形成自治，從而激發團隊的主觀能動性，釋放各個團隊的創新能力，這就自然形成了企業想要的扁平化管理。
但就目前來說，提到微服務，則越來越多地聚焦於其在技術層面的具體實現方式了，進一步說，就是企業該通過什麼樣的技術架構，來支持應用的微服務化。那麼，微服務架構具體有什麼標準化的技術層面的清晰定義呢？
如果我們解讀一下現在一些頭部互聯網公司展示出來的它們各自的技術框架，就會發現，其實每家公司都有自己不同風格的微服務架構。但總的來說，我們還是可以通過一些原則來歸納出微服務架構的基本特徵的：
1：系統由兩個及以上服務組件組成，這些組件將其自身功能以服務的形式展現出來，並按照預先定義的協議進行交互，每個組件服務對應一個業務目標，各個服務組件之間是松耦合的；
2：系統應該是與編程語言無關的，某一個服務組件可以用Java 開發，與此同時，另外一個服務組件可以用.NET開發，單獨某一個服務組件在實現時的技術選型，不會影響到整個應用架構；
3：系統的數據庫應該是去中心化的，每個服務組件都可以享有自己的數據庫，且該數據庫僅供該服務組件自己使用，任何其他服務組件都不能讀取或者修改該數據庫中的數據；
4：系統中的每個服務組件都是可以自行部署和測試的，任何一個服務組件在測試、部署和運行的時候都不應該依賴其他服務組件或者資源；
5：任何一個服務組件的故障都應該是隔離的，單個服務組件的故障不應該拖垮整個應用，也不應該影響其他服務組件。
以上五項原則，基本是適用於所有微服務架構的，不過對於這樣的微服務架構，在很多長期為傳統企業設計信息化系統的人來看，與所謂的共享服務、能力開放等，並沒有本質區別，難道那些傳統企業的信息化系統，一直都是在遵循微服務架構來設計開發的麼？
事實上，傳統企業進行信息化系統開發時，確實也會規劃一些能力開放組件，形成一個共享服務層，供上層業務調用，這也的確符合上面的五點原則。不過，微服務架構的概念畢竟是從互聯網公司叫起來的，而互聯網公司的系統相比傳統企業的信息化系統的區別包括：數量極多的服務組件、各個服務組件的持續和頻繁的迭代，以及極為靈活和複雜的服務調用。所以僅僅將共享功能組件堆砌在一起，即便可以從系統邏輯上劃分出一箇中臺微服務層，但卻不能稱之為被業界所公認的微服務架構。而完整的微服務架構，還應該具備下面四點特徵：
1：系統應該有自動化測試能力，因為對於互聯網公司來說，很多微服務組件，版本迭代都非常頻繁，且涉及到的前端服務調用也較為複雜，所以微服務在構建、測試，到上線的整個週期中，如果沒有自動化測試，微服務架構速度快的特徵，就是一紙空談。
2：相比傳統企業信息系統中較少的共享服務，互聯網公司的服務組件非常多，所以需要有非常強的服務治理能力，包括服務註冊、服務發現、配置管理、監控限流、路由分發、網關調用、負載均衡，以及鏈路追蹤等等
3：同樣，對於互聯網公司大量且迭代頻繁的微服務組件，其部署運維工作，僅靠人工操作將很難支撐，每個組件必須能夠實現便捷的持續集成、持續部署、持續監控、持續反饋和持續改進，這一系列流程的實現，應該有一套支持開發運維（DevOps）的高效工具鏈。
4：此外，基於雲的容器服務，能夠讓整個微服務架構有一個好的基礎設施層支撐，從而能夠快速地進行服務組件的部署和交付，因此也可以看作是微服務架構的重要組成部分。
關於微服務的更多幹貨，這裡還有本[微服務實踐]電子書，系統地介紹了微服務的相關知識，有興趣的朋友可以根據文末線索獲取。
下面再說說中臺與微服務的關係。
中臺是以核心能力微服務化為中心，去支持上層應用的快速創新、快速響應和快速迭代，同時消除煙囪式子系統、避免重複造輪子，以及拉通信息系統，重塑組織協同。
中臺和微服務架構，可以看作是有交集的兩個領域的概念，中臺更偏業務、偏戰略、偏組織；而微服務架構則更偏重具體的技術實現。
微服務架構可以看作是實現中臺戰略的技術手段，但卻不代表中臺的全部。而作為一種系統架構，微服務架構不僅僅可用於中臺，邏輯上位於前臺和後臺的功能組件或系統，同樣能夠以微服務化的形式進行開發和實現。不過，由於中臺的定位就是共享服務中心，所以微服務架構的價值和優勢能夠得到更為充分和突出的展現。
最後再說說，什麼樣的傳統企業才需要進行微服務化改造以及構建中臺？筆者認為，至少應該具備下面兩點特徵：
1.企業要具備一定規模，信息化建設達到了一定水平，應用系統較多，且有較多的面向C端海量用戶的業務產品，並有海量的數據積累；
2.企業內部有多條業務線或多級組織架構，且各個業務單元或各級組織，都有自己的系統，且各個系統中存在很多重複建設的功能模塊；
3.企業的互聯網前端業務越來越多，包括APP、小程序、網站等等，且前端業務需要不斷響應用戶需求、持續創新、快速迭代。
對於不具備兩點以上特徵的企業，盲目追求技術的“先進型”，強行構建中臺以及進行微服務化改造，重構和遷移現有系統，很可能會是一件得不償失的事情。這不僅僅在於高昂的成本換不來多少效益，而更重要的是，中臺和微服務架構能夠幫企業解決的問題太少，卻可能因為增加了系統的複雜性，而多了很多設計和運維成本。
此外，在更高的企業管理層面，如果傳統企業沒有與中臺戰略相匹配的管理理念和組織架構層面的調整，那麼微服務與DevOps也是無法順利推進下去的，中臺戰略很可能會名存實亡。
創作不易，歡迎朋友們關注、評論、轉發。如商業轉載或其它，請聯繫：keji5u（科技無憂訂閱號）
閱讀更多 科技無憂 的文章
