前面談過很多關于數字化轉型，云原生，微服務方面的文章。
雖然自己一直做大集團的SOA集成平臺咨詢規劃和建設項目，但是當前傳統企業數字化轉型，國產化和自主可控，云原生，微服務是不可逆的技術發展趨勢。
企業IT架構轉型，不只是單體應用簡單拆分為微服務這么簡單。而是整個IT應用架構模式發生巨大的變化，核心思想仍然是平臺+應用的構建模式。
而這個平臺也不是簡單的IaaS平臺或PaaS資源調度平臺，而是當前主流說法的云原生技術中臺。不僅僅提供容器云和容器資源編排調度，還得提供消息，緩存，數據庫等各種技術服務能力，徹底實現從IT基礎設施從資源層到邏輯層的抽象。
云原生技術中臺-平臺+微服務
在單體應用微服務化后，前期的軟件研發和交付過程，后期的軟件監控運維和治理能力都必須配套跟上。因此完整的云原生整體解決方案里面包括了DevOps持續集成和交付，微服務治理兩塊核心內容。
在當前云原生和微服務發展趨勢下也可以看到，傳統的SOA集成平臺和ESB逐步會被API網關和能力開放平臺所取代。而SOA治理也逐步變化為微服務治理。
雖然SpringCLoud框架體系里面已經有類似Zuul的網關組件，但是整個規劃里面我們還是將API網關單列出來，因為整個API網關不僅僅應用于微服務架構體系和對外API接口暴露，更加重要的是將成為我們后續構建能力開放和服務能力聚合平臺的一個關鍵集成平臺。
整個云原生平臺規劃將圍繞以下兩點展開。
- 容器云平臺和DevOps支撐
- 微服務全生命周期管理和能力開放
對微服務架構的支持和融合
在原來談微服務架構的文章一直在強調，微服務架構不是簡單的使用SpringCloud開發框架，更加不是簡單的提供Rest API接口服務就是微服務架構。
更加重要的是微服務模塊如何拆分，微服務API接口服務如何識別，粒度如何把控。其次更加重要的是微服務框架體系如何和DevOps支撐平臺融合，如何和API網關集成融合，包括如何和后續的監控運維平臺融合。這些都必須考慮清楚，才能夠形成DevOps的基礎能力平臺。
在微服務架構實施過程中，需要有一系列的開發規范和技術標準也需要提供，包括模塊的劃分設計，API接口服務識別和定義，代碼開發，測試，數據庫拆分，安全，分布式事務處理，部署上線，監控，運維等，這些標準都必須定義清楚，否則整個微服務架構實施后由于模塊拆分的更細，沒有很好的研發過程管控，技術標準約束你反而會覺得比原來單體應用開發更亂。
PaaS技術服務平臺構建
在原來談私有云PaaS平臺的時候就經常談到里面有一個技術平臺提供類似4A，流程，安全，緩存，消息，日志等各種技術服務能力。而在整個微服務架構體系實施中，也必須有一個完整的技術平臺，每一個技術服務就是一個獨立的微服務組件模塊，可以獨立部署和管控。
技術平臺的各種技術能力，仍然是以獨立的技術服務方式提供給整個微服務架構體系中。在整個微服務架構體系里面可以看到，內部的各個業務微服務模塊調用技術服務API接口就不需要通過API網關，而直接走微服務注冊中心即可。
監控平臺-端到端的監控能力
對于監控平臺可以看到，需要提供從資源到服務再到應用的端到端監控能力。最底層是服務器，數據庫，中間件等資源監控。上面是服務和服務鏈監控，再上面是應用監控和端到端業務流程監控。
資源，服務，應用三個層面的應用之間本身又相互影響，存在勾稽關系，一個是資源最終暴露的性能問題可以反追溯到具體的應用業務功能功能，而具體的業務流程端到端監控本身又可以詳細分析到某一個業務功能點和接口服務的性能數據。
微服務治理
微服務治理概括來說，實際上關鍵包括兩個部分。
- 其一是微服務應該如何拆分，API接口如何設計
- 其二是運行期如何監控，管理，運維
上圖給出的圍繞微服務全生命周期管理和基于服務度量體系的持續運維監控兩個方面展開，對于一些二級的內容在該圖暫時無法展開，比如常說的服務版本管理，服務依賴分析也是微服務治理的關鍵內容，暫時在該圖沒有體現。
在運行期還有一個關鍵思維的轉變就是不是簡單的發生問題故障后的運維治理，而是應該基于監控預警分析下的主動的技術運營和SLA服務等級提升。
如果你要去給別人做微服務治理，實際上是客戶在確定了微服務架構后就需要介入，包括選擇什么樣的開發框架，采用哪些開源技術，這些開源技術如何整合，微服務如何拆分，微服務開發過程如何規范化，如何持續集成和部署，API接口如何設計，微服務間如何集成，運行期微服務如何進行狀態和性能監控，如何進行安全，日志，限流等管控。
能力是開放平臺-大生態建設的基礎
構建微服務開放框架，DevOps能力支撐平臺或API網關可以實現的內部完整的微服務架構化，而如果要做到對外運營，服務聚合和大生態體系建設，更加重要的就是能力開放平臺的建設，這個平臺最終實現內部能力的開放，外圍能力和生態的聚合，并走向產品化+運營化的發展方向。
能力開放在前面我談到過，一個是完全自身已有能力的開放，一個是構建開放平臺聚合外圍能力。而只有聚合外部能力才是構建大生態，可持續發展的關鍵。能力開放也不是簡單接入一個API接口，更加重要的是提供從能力開發接入，能力運行，能力消費訂購，能力監控運維的全生命周期管理能力。
基于云原生平臺的開發和集成
傳統企業IT架構轉型過程中可以看到幾個關鍵點的變化：
- 傳統的單體應用-》獨立自治的多個微服務模塊
- 傳統的PaaS平臺+ESB服務總線基礎-》DevOps+容器化PaaS+API網關
簡單來說就是你要做好IT架構的微服務化，中臺化轉型，那么你支撐平臺這件事情也得跟上，平臺提供共性能力支撐和能力開放，支持多個微服務模塊持續集成和交付。在后期監控運維還得配合DevOps理念跟上，形成要給完整的IT生命周期閉環管理。
在進行API網關和DevOps支撐平臺研發的時候，自己一直在思考兩個重點，就是業務驅動和快速迭代，即基于實際的業務使用場景來思考和提煉產品應該具備哪些功能，實際的功能優先級是如何的。而業務場景驅動里面最重要的就是最終的用戶角色分析，不同的用戶角色實際的問題和需求是如何的。
底層平臺如何提供管控治理能力和易用性？
拿API網關來說，不論是SpringCLoud框架里面的Zuul微服務網關，還是類似Kong，Orange等開源API網關產品，最早可能只是一個具備代理和路由轉發，具備基本的安全，流控能力的網關引擎，連基本的管理界面都沒有，到現在類似Kong已經形成了基本的管理前臺界面，能夠方面的進行API注冊接入，各類插件模塊的配置和添加，但是最終的使用者是誰呢？
我們分析類似Kong網關產品最終的使用者是偏業務系統本身的開發人員的，而不是面向統一的業務系統集成商或平臺能力提供商的。
先不說類似我們當前集成平臺實施中提供的各種服務接入，服務訂購等各種服務流程，就連最基本的業務系統視角的功能也很難獨立提供。
即業務系統開發人員是沒法上這個管理平臺的，那么如果業務系統需要查看注冊接入了哪些服務，配置了哪些規則，具體服務調用實例和日志信息的時候，都無法提供這些能力，都需要進行定制化開發。而恰好這些當前開源API網關產品的痛點，可能就是定制化要給API網關的管理平臺產品的優點。
也就是說當前API網關產品更多是面向已有微服務架構體系內的API能力對外開放需求來做的，而不是基于微服務架構體系里面多個業務系統，開發廠商間接口協同思路來做的。因此要將API網關產品轉變為一個具備多系統集成能力的集成類產品，中間還有很多工作要做。
微服務實施配合研發過程和團隊管理
當一個大的應用拆分為多個微服務并分配給多個廠商開發時，整個組織團隊管理，研發過程管理，相互協同集成就變得非常重要。
舉例來說，一個大的業務系統按微服務架構思路招標，比如一個供應鏈系統，招標的時候即按微服務模塊劃分思路拆分為了招投標管理，采購管理，供應商管理三個獨立的技術標，后續三個開發商中標，每個開發商開發時候都采用微服務架構，比如招投標管理里面會繼續拆分微多個微服務模塊，而這個時候我們看到就存在兩類接口集成問題，在實際協同上需要采用不同的集成策略來處理。
- 招投標內部多個微服務組件間接口集成：同一廠商，采用服務注冊和配置中心即可，不需要網關
- 招投標和采購管理兩個大子系統間集成：不同廠商，需要采用API網關來完成集成和協同
而這些就是實際我們面對的業務場景，集成場景需要這樣來做，當你真正做到現場的實施項目的時候，這些關鍵需求自然會碰到。但是你如果完全是研發驅動，脫離市場和一線客戶需求，那么最終產品將出現很多關鍵功能性缺失。
那么當你無法在前期通過需求調研或競品分析各種方式采集到完整的用戶需求，并整理為產品需求的時候，你需要考慮的就是基于敏捷開發思路下的產品快速迭代。
而快速迭代本身又有兩個重點。
- 短周期：必須是短周期，1周到4周，短周期目的就是真正讓進度可視，可見，可驗證。
- 可使用：可使用是一個關鍵點，即迭代發布的版本一定是可以發到現場讓用戶真正開始使用的版本。
任何迭代版本的發布，是否可用必須是一個關鍵的衡量敏捷項目管理和迭代質量的指標。舉個例子來說，我們準備1個月發布V1.0初始迭代版本，但是發布后發現這個版本根本用不起來，我們又陸續發布了1.1，1.2，1.3三個小版本才真正用起來，而這三個小版本的發布可能又用了2個月的時間。也就是說你的產品真正用戶開始使用，真正開始支撐業務用了3個月的時間。那么這種形式主義上的迭代沒有任何意義。
通過迭代的方式是讓你進一步的收集需求和優化改進，但是一定不是關鍵需求缺失導致產品根本無法使用。如果一個迭代版本無法使用，那么發布到現場本身也沒有任何意義。
冠以敏捷而拋棄過程并導致混亂，太強調溝通而無法進行基礎工件交付，開起來很美好的短周期產品發布但是卻是一個無法真正用起來的半成品，這些都是偽敏捷的自欺欺人做法。
