在互聯網技術突飛猛進的年代，在電商業務風聲水起之時，在軟件領域的變革悄然而至的“雲計算”時代，"雲"成了各大傳統行業軟件開發商和各大電信運行商爭論不休的議題。
（特別說明：本文中所述觀點，是個人在面向互聯網，面向生態，面向急速交付，面向持續演進的實踐基礎上對業務不確定性和應對業務不確定性設計方式及服務能力沉澱的總結和領悟。非官方性言論，請勿對號入座，個人之愚見，不喜勿噴！）
1 炮火中勇往直前
記得那一年我們是在炮火中度過的，雖然不是在一線，但是快節奏和高壓毫不遜於一線的交付局點。據統計那時我們的系統已佔據了90%的市場份額。用現在的話說，我們躺着也能贏，但是我們真的能贏嗎？那剩下的10%的市場可是最難啃的北美市場，除了苛刻的市場準入要求外，貿易保護政策也是我們無法逾越的鴻溝。
記得那年我們的節奏變得飛快，曾經一年發佈一個商用版本變成一年發佈兩個商用版本到最後一年交付四個商用版本，簡直是恐怖得要人老命。人員相繼流失，局點需求應接不暇，技術債也是債臺高築，更讓人吐血的是代碼質量達不到保證，日常維護備嘗艱辛，這可是有着十年悠久歷史的系統不知經過多少人手，代碼腐化嚴重，if else 多如牛毛，架構就不用說了，最讓人無法忍受的是這個系統是異構系統，C++、Java、Phthon等語言，據我師父說這是有1500W+代碼的系統，打個包比操作系統還大。
記得那一年我們非常的虛，可不是腎虛的虛，是虛脫的虛。最怕的就是過點了，簡直是內心陰暗了，虛脫的要跪但是沒辦法，咬着牙補丁還是要出的，版本還是要按時GA的，局點需求還是要交付的，反正就是既要又要還要。
1.1 泥沼中的掙扎
前面說了這麼多，我無非就是想描述這個泥沼有多深，無奈詞窮。我想這是所有軟件都會遇到的通病，代碼腐化、架構腐化，雖然有小範圍的重構可畢竟杯水車薪。這可是全球擁有90%市場份額的系統，市場存量可想而知，到最後我們的開發變成了打補丁。
1.1.1 面臨的困境：
內憂：代碼泥潭，維護成本，補丁發佈成爲日常，軟件架構腐化
外患：公司內部業務兼併，外部行業強敵
交付：局點需求應接不暇
測試：迴歸迭代成本高昂
矛盾：開發&測試之間的矛盾甚至敵對
方向：前無古人後無來者，走在行業最前沿，沒有目標和方向
團隊：團隊人員流失
政治：不同地域的法律條款積極人文因素
1.1.2 業務不確定性：
1 局點需求變化多端；
2 業務是否有複用價值；
3 服務能力如何沉澱；
4 軟件商業化；
5 SDN(軟件定義網絡)如何實施；
6 業務能力和流程如何編排；
1.2 黎明的曙光
軟件危機總會發生的，也總有應對之道，有戰略之道也有戰術之道，但此道非彼道總是要另起爐竈。隨風潛入夜，潤物細無聲，電商、雲計算、生態、互聯網+、微服務、Devops這些前沿的詞彙漸漸落到了實踐應用中。開發語言從傳統的C++走向Java/NodeJs/Python/Go;軟件風格從面向過程走向面向對象/面向服務/面向接口/面向微服務;複用力度從函數複用走向功能複用模塊化/組件化/平臺化/雲化。
1.3 未來的呼喚
其實我在那個時候心裏對這個系統的演進方式完全沒有概念，對於面向互聯網，面向生態，面向極速交付，面向持續演進並沒有過多深入的思考，也不覺得會解放我們的生產力。那個時候在互聯網方面，內部已投入大量的人力財力，甚至有行業內的諮詢顧問指導我們在這一塊的技術落地。
1.3.1 服務化解耦
爲什麼要服務化解耦，我不說大家也明白。其實，微服務很多人都誤解了，我們不是爲了服務化而服務化，不是爲了最求最新的技術而採用服務化。首先，微服務是爲了解決單體應用架構臃腫服務耦合的問題。其次，我們是爲了解決團隊協作的問題。最後我們是爲了解決業務域服務編排和組裝的問題。
當時的背景下我們是希望通過採用服務化架構，能夠讓各服務之間松耦合，可根據業務場景靈活的進行服務編排和組裝，讓每一個服務都成爲底層能力，實現可插拔和業務定製。這樣做的好處是微服務都運行在覈心的基礎框架之上，不同的廠商和局點可以按需定製產品。
1.3.2 開放易集成
在這一塊，爲了更好的面向生態，對生態提供開放能力，在北向提供了開放的OpenApi接口，供騰訊等雲業務上接入。南向提供驅動插件機制，供第三方快速接入，基礎服務提供服務化接口供第三方快速開發。
1.3.3多租戶支持
基礎數據模型增加租戶維度，各服務提供多租戶模型，提供多種數據共享方式，提供租戶應用供租戶自運維。
1.3.4 彈性擴容
服務支持多實例，通過擴容實例支持更大的管理容量。
1.3.5 高可靠性
服務多實例負載分擔，支持主備和集羣保護。
1.3.6 靈活部署
系統架構能靈活根據用戶的場景進行組網部署，如單機模式，集羣模式。
2 行業最佳實踐
2.1 服務化改造
服務化的改過過程我們經歷了三個階段：
第一個階段：C++/Java異構架構走向Java,從集中式走向分佈式；
第二個階段：微服務化；
第三個階段：Pipline的接入/Devops模式的接入；
2.1.1運行容器的定製
我們在基於開源的Tomcat基礎上對其進行了安全加固，做了定製化開發，我們的系統運行在定製化的Tomcat之上；後來開始往Docker方向演進。
2.1.2 服務路由
我們對服務路由進行改造，服務路由基於最短路徑的原則，服務間有限調用本JVM的服務提供者，其次是同機、同VM、同機房最後是跨網絡調用。
2.1.3 服務調用方式
同步調用、異步調用、並行調用
2.1.4 服務故障隔離
線程級別、進程級別、容器級別、VM級別、物理機級別故障隔離，監聽和守護。後續在同探索容器化沙箱化等方式。
2.1.5 分佈式事務
在做了服務化後我們進一步對不同的業務域做了拆分，我們進入了微服務架構。當我們踏上了微服務這趟列車，數據一致性成爲做大的考驗。這一塊內部在向數據層這一環節開發自己的中間件。這裏可能有人有疑問，開原件那麼多爲什麼不用？運營商系統對軟件安全性要求非常苛刻，一般我們不使用開源中間件，都是自己造輪子。對於萬不得已只能使用開原件，這個就需要層層審批。
2.1.6 分佈式緩存
我們嘗試引入緩存機制
2.1.7 分層冗餘
我們使用外部路由和內部路由
2.1.8 數據一致性
借鑑各種一致性方案和一致性算法出了自己的一致性方案。
2.1.9 分佈式鏈路跟蹤
借鑑阿里的鷹眼和谷歌的論文，造出了自己的輪子。
2.2服務自治
1 服務獨立交付
2 服務並行安裝
3 服務並行啓動和停止
4 服務原子化的業務單元，完成單一業務職責
5 服務數據庫去中心化
6 通過配置方式定製服務能力
7 服務無狀態
8 Http會話數據共享
9 數據禁寫本地文件系統
2.3 面向開放生態
開放平臺、北向開放API(面向騰訊、阿里、京東)
南向提供驅動插件機制
2.4 雲龍見田-基礎設施自動化
Devops基礎設施，面向組織、面向研發過程、面向集成驗證環境、面向運維。
2.5 服務能力的沉澱
從面相業務的架構向面向生態的架構演進
從微服務向領域模型沉澱
領域能力商業化演進
面向生態開放
2.6 脫胎換骨
在進行一系列的演進之後，我們的產品成爲了具有特色的SASS平臺。 其分爲三個層面對外提供服務，分別是數據面、管理面、運維面。其具備了底層的運行內核，業務基於微服務註冊在內核之上。
在演進方面，產品在架構設計上主要的思想是：
-
產品服務與平臺分離的插件化架構： 平臺提供服務包註冊機制，實現業務方的服務包的註冊。業務代碼只允許存在於業務域的微服務中，與平臺代碼嚴格分離。業務包的代碼配置庫也與平臺的代碼庫分離，通過二方包的方式，提供給容器加載。（簡而言之，平臺相當於一個操作系統內核，業務運行在內核之上）
-
管理面/運維面/數據面視角分離的架構： 管理面/運維面/數據面是基於用戶不同的角色，從功能上做了劃分。管理面可以對租戶內部的賬號、功能模塊、內部操作權限進行管理；運維面用於支持租戶在系統內存、流量、數據庫使用情況等方面的運維管理；數據面是租戶的業務操作工作臺，用於日常的業務定義和下放；
-
基於服務編排的業務間隔離架構：產品需要能有按運營商需求定製軟件包的能力，軟件提供商在Devops上選擇沉澱後的商業能力(微服務/產品/功能)進行定製化的業務編排。