前面談過很多關於數字化轉型，雲原生，微服務方面的文章。
雖然自己一直做大集團的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個月的時間。那麼這種形式主義上的迭代沒有任何意義。
透過迭代的方式是讓你進一步的收集需求和最佳化改進，但是一定不是關鍵需求缺失導致產品根本無法使用。如果一個迭代版本無法使用，那麼釋出到現場本身也沒有任何意義。
冠以敏捷而拋棄過程並導致混亂，太強調溝通而無法進行基礎工件交付，開起來很美好的短週期產品釋出但是卻是一個無法真正用起來的半成品，這些都是偽敏捷的自欺欺人做法。
