記得14年初下定決心重構(gòu)系統(tǒng)的那一刻 ，“一切從簡”的欲望尤為強烈，只因事情已經(jīng)被“復(fù)雜”堵得水泄不通，其實歸根到底還是過往自身的工具化思維局限了問題“最優(yōu)解”的選擇。對于一個“入世未深”的小伙來說，“簡單”僅僅是簡單。但無論如何，能把“簡法”付諸行動，就已經(jīng)不很簡單了。
簡法一：為什么不把這坨該死的代碼拆開？
每當代碼打包發(fā)布的時候，一個上百兆的部署文件讓我深感憂慮。我的擔憂并非空穴來風，一次又一次的瓶頸讓我驗證了這該死的擔憂。面對這樣一個龐然怪物，就算無數(shù)個“通宵”也削減不了我對它的力不從心，“分解”成為了我當時的唯一想法。因為“分解”是我們?nèi)祟愄幚韽?fù)雜的一種常識化手段，它能讓我把一條復(fù)雜的數(shù)學題逐一破解，也能讓我把一項艱巨的任務(wù)分而治之，更讓我看到了人類從“自給自足”到“專業(yè)化分工”的魅力。
簡法二：除了MVC，我還能如何選擇？
無可否認，MVC是互聯(lián)網(wǎng)時代的“王者榮耀”，但隨著移動互聯(lián)網(wǎng)的發(fā)展，我試圖尋找另一種更適合多端消費的服務(wù)化抽象模式。如果我只是單純地把沉重的SSH切換到當時較為流行且輕量的SSM，其實并沒有太多本質(zhì)上的區(qū)別。我們當時的這種“服務(wù)化”分解其實更多地想給“消費者”提供一種輕量化、標準化、抽象化的服務(wù)支撐，如果要用專業(yè)術(shù)語來形容，可能SOA（面向服務(wù)架構(gòu)）更為貼切。但ESB和WS作為當時SOA的主流實現(xiàn)和工具，它們的“沉重”讓我望而卻之。
簡法三：繼續(xù)找合適的“輪子”還是“自造”輪子？
有想法對于一個年輕人來說再正常不過，但把能把這想法付諸實現(xiàn)還是需要一定的付出、勇氣和機遇。才疏學淺的我在當時并未看到“服務(wù)化”的普及，選擇一款成熟且契合自己思路的工具也不是一件容易的事，又或許是我內(nèi)心當時那份熱血澎湃的重構(gòu)欲望在日益膨脹。幸運的是，開放的平臺給了我足夠開放的心態(tài)、空間和信心去打造屬于我們的“輪子”。
簡法四：輪子的思考
“簡單”是我們設(shè)計的首要原則，因為簡單賦予了靈活，提高了效率、增強了可控，而且自主研發(fā)的約束范圍也會遠遠大于工具的選擇，為“簡化”創(chuàng)造了無限可能。開源工具的思考邊界可能更多地會集中在技術(shù)引擎和技術(shù)規(guī)范二者之間，因為它必須抽象在應(yīng)用場景之下才能達到一定的通用性，所以開源的考慮會非常周到且功能齊全，但會存在一定的“臃腫”和“個性化”局限，這也是我們“自造輪子”的重要考慮之一，但更重要的還是從本質(zhì)出發(fā)。
簡法五：技術(shù)引擎的思考
“服務(wù)化”的設(shè)計理念會把應(yīng)用根據(jù)“領(lǐng)域邊界”分解成一個個獨立的“服務(wù)進程”。其實，劃分后的應(yīng)用系統(tǒng)跟操作系統(tǒng)還是有幾分相似之處，服務(wù)好比進程，線程好比服務(wù)的業(yè)務(wù)執(zhí)行單元。事實上，它們在運行過程中就是這樣一種上下層的對應(yīng)關(guān)系。
線程的執(zhí)行是基于棧幀的“跳進跳出”，而業(yè)務(wù)的執(zhí)行是基于“流程”的線性執(zhí)行。“流程”是業(yè)務(wù)執(zhí)行的線性抽象，對“流程”的分解、定義、組織和管控恰恰就是我們對“技術(shù)引擎”設(shè)計的關(guān)鍵所在。
簡法六：技術(shù)引擎的實現(xiàn)
對流程的抽象并非想說明我們“輪子”的獨特之處，而是嘗試對流程本質(zhì)進行重新理解。因為本質(zhì)，所以無論SSH還是SSM都能作為該抽象流程的一種實現(xiàn)。但是，我們要做的是嘗試重新透過現(xiàn)象看本質(zhì)，然后基于本質(zhì)之上一磚一瓦重新打造出我們“服務(wù)化”理念的另一種實現(xiàn)。
一張白紙的背后可能隱藏著數(shù)十道工序的運作，我們“輪子”每磚瓦的堆砌同樣少不了對系統(tǒng)從始至終、由里到外的無數(shù)次觀察和思考。每一次的重構(gòu)都千差萬別，每一次的放棄都異常掙扎，但每一次都更接近于自己的內(nèi)心。
除了服務(wù)交互協(xié)議層外（Service Interaction protocal），我們把框架總體劃分為框架服務(wù)（Framework Service）、基礎(chǔ)服務(wù)（Base Service）和業(yè)務(wù)服務(wù)（Business Service）三個層次，各層次服務(wù)都是由定時器模塊組件（Timer）、初始化模塊組件（Initor）、銷毀模塊組件（Destoryer）、業(yè)務(wù)前置模塊組件（ SB_Module）、業(yè)務(wù)后置模塊組件（SA_Module）以及業(yè)務(wù)實現(xiàn)模塊組件（Services）組成。從結(jié)構(gòu)上看，每一層的服務(wù)都內(nèi)嵌于它上一層的服務(wù)之中，讓各種模塊組件形成了一種高約定、標準化、插拔式的切面規(guī)則。
從開發(fā)框架的切面結(jié)構(gòu)上看，框架的規(guī)范化約束已經(jīng)弱化了傳統(tǒng)的三層結(jié)構(gòu)模式，把一切非核心邏輯“邊緣模塊組件化”，重點關(guān)注業(yè)務(wù)的核心邏輯實現(xiàn)。
簡法七：技術(shù)規(guī)范的定義
因“欲望”的驅(qū)動，“自由”成為人性放飛自我的向往，但無拘無束的“自由”往往會對人性的自我控制形成嚴峻的考驗，否則不會“無規(guī)不成圓”。“自由”和“約束”看似一種魚和熊掌的關(guān)系，實際上，“約束”是邁向“自由”必不可少的前提。所以，“約束”可以讓我們盡量地減少了配置、封裝和依賴，盡量以一種簡潔、高效且通俗易懂的工具形態(tài)讓執(zhí)行者“自由地”聚焦在問題的本質(zhì)之上。
以上的服務(wù)定義主要源于我們對技術(shù)引擎的流程抽象分析。但業(yè)務(wù)服務(wù)（BUSINESS）本身除了具備核心業(yè)務(wù)的能力支撐以外，背后還隱藏著一個對核心業(yè)務(wù)的管理職責（俗稱服務(wù)信息管理平臺）。因此，我們繼續(xù)把服務(wù)按功能性類別分解為“面向服務(wù)支撐（SOP）”和“面向服務(wù)管理（SMP）”兩大類服務(wù)類型，無論業(yè)務(wù)支撐還是信息管理都實現(xiàn)了前后端的分離，把輕量化SOA演繹得淋漓盡致。因為基礎(chǔ)服務(wù)與業(yè)務(wù)服務(wù)的強關(guān)聯(lián)性，基礎(chǔ)服務(wù)同樣被細分為BASESOP和BASESMP兩大類基礎(chǔ)服務(wù)。
服務(wù)目錄命名規(guī)范中的xxx為業(yè)務(wù)服務(wù)自定義標識，模塊組件命名規(guī)范中的XXX為三位純數(shù)字組合，除了唯一性的約束以外，還具備了內(nèi)部模塊組件（除業(yè)務(wù)實現(xiàn)模塊）執(zhí)行順序的規(guī)范化約束，這一點跟Linux的運行級別中的運行腳本命名規(guī)范還是有幾分相似之處（KXX.../SXX...）。
簡法八：應(yīng)用規(guī)范的定義
從某個角度來看，人性的“懶惰”是社會進步的動力，它激發(fā)了人類創(chuàng)造的欲望來釋放自己并減少一系列人為的不穩(wěn)定性。但在那些尚未被工具自動化或智能化所覆蓋的領(lǐng)域，適當?shù)奶崆凹s束和規(guī)范同樣是對人為管理的一種自動化體現(xiàn)。
框架的會話上下文（SessionContext）是線程流程代理及其模塊組件解耦的關(guān)鍵所在，它承載著整個線程生命周期的狀態(tài)信息，如業(yè)務(wù)會話（抽象）對象、請求報文對象（JSON）、響應(yīng)報文對象（JSON）、模塊組件內(nèi)部執(zhí)行上下文以及關(guān)系數(shù)據(jù)庫事務(wù)控制等數(shù)據(jù)和信息。而框架服務(wù)內(nèi)更多地集成了流程的一些應(yīng)用規(guī)范化實現(xiàn)，如服務(wù)并發(fā)控制攔截，數(shù)據(jù)統(tǒng)一解析、安全攔截驗證 、數(shù)據(jù)統(tǒng)一響應(yīng)輸出以及統(tǒng)一規(guī)范化日志記錄等基礎(chǔ)應(yīng)用實現(xiàn)。此外，框架還集成了如關(guān)系數(shù)據(jù)庫、內(nèi)存數(shù)據(jù)庫、遠程過程調(diào)用等規(guī)范化的“數(shù)據(jù)適配器組件”，讓業(yè)務(wù)的核心邏輯更加輕量和清晰地聚焦在業(yè)務(wù)層面（Service）。最終，應(yīng)用服務(wù)基于標準化的應(yīng)用規(guī)范之上實現(xiàn)了全方位的流程代理及管控。
簡法九：服務(wù)網(wǎng)絡(luò)
經(jīng)濟學認為“交換驅(qū)動發(fā)展”，這是人類從自給自足發(fā)展至全球化分工的一個演變“真理”。而互聯(lián)網(wǎng)的出現(xiàn)更讓交換出現(xiàn)了前所未有的低成本、大范圍，甚至把數(shù)量龐大的“物”也“卷入”了交換的浪潮，把未來的一切想象無限放大。“服務(wù)化”應(yīng)用同樣是信息交換驅(qū)動發(fā)展的一種演變和趨勢，一個個具有“獨立領(lǐng)域行為”的個體服務(wù)在信息交互過程中增加了各種應(yīng)用行為“涌現(xiàn)”的可能性。
服務(wù)發(fā)現(xiàn)中心（KingWorks-RDC）在服務(wù)網(wǎng)絡(luò)中扮演了信息登記服務(wù)的角色，有點類似于DNS服務(wù)在互聯(lián)網(wǎng)中的定位，“模糊”了主機的位置，解耦了服務(wù)之間的關(guān)聯(lián)。歸根到底，RDC是一個基于服務(wù)開發(fā)框架（KingWorks-SDF）建設(shè)的“動態(tài)解析”支撐類信息服務(wù)。而微網(wǎng)關(guān)（KingWorks-MSG）則是一個內(nèi)置于服務(wù)開發(fā)框架的服務(wù)請求代理組件，除了具備基于RDC動態(tài)代理的實現(xiàn)，還兼顧了“靜態(tài)解析”的預(yù)留，為一些“穩(wěn)定”的服務(wù)應(yīng)用場景省去了動態(tài)的消耗。
服務(wù)信息的動態(tài)解析是基于“服務(wù)信息中心”組件的周期更新，此外，RDC還預(yù)留了“服務(wù)變更”主動推送通知功能，需要此功能的服務(wù)只需要通過“推送開關(guān)”配置即可實現(xiàn)RDC的服務(wù)變更實時推送通知（非強一致性），提高本地服務(wù)對敏感信息更新的實時性。另外，對于一些存在多服務(wù)區(qū)域（多局域網(wǎng)）的應(yīng)用場景，我們通過對本地服務(wù)信息（IP1&PORT1）和外部服務(wù)信息（IP2&PORT2）的區(qū)分讓“混合云”的服務(wù)化應(yīng)用成為可能。
簡法十：自動化管控
凡事都有兩面性，好壞優(yōu)缺得失并存，但是善于“揚長補短”的人類注定不會讓社會成為一個“零和游戲”。當我面對服務(wù)化多節(jié)點所導(dǎo)致的高額人工維護成本時，自動化工具將是這場“正值游戲”的重要手段。
自動化管控服務(wù)（KingWorks-OPS）是整個服務(wù)化應(yīng)用的管控平臺。底層主要是由一個C/S模式的腳本任務(wù)調(diào)度引擎支撐，C是一個內(nèi)嵌于應(yīng)用服務(wù)的任務(wù)執(zhí)行代理（OPS-Agent By Python），提供了定時和實時的執(zhí)行入口，而S則是一個任務(wù)調(diào)用管控服務(wù)，集中式對所有服務(wù)任務(wù)進行管理、配置以及調(diào)用。基于引擎之上的，就是面向場景的集成，如服務(wù)統(tǒng)一配置與管控、數(shù)據(jù)集中可視化監(jiān)控、自動化告警處理以及自動化實施等場景的擴展。
簡法十一：服務(wù)化協(xié)作
人的一生其實可以歸納為只是自己與大腦的一場游戲，行動受控于思想，且行為上變化更多是自身的潛在思維與受控思維的一場較量，就像我們應(yīng)用從傳統(tǒng)到服務(wù)化的轉(zhuǎn)變無非就是一場“自我驅(qū)動”對“隨波續(xù)流”發(fā)起的挑戰(zhàn)。改變了思維，改變了技術(shù)，當然，也改變了我們團隊的協(xié)作方式......
“DEV-TEAM”主要是由1個組長+2~3個組員組成的服務(wù)開發(fā)小組，基于開發(fā)框架的模式我們把小組主要劃分為前端小組（Android、iOS、H5）以及服務(wù)端小組（設(shè)計、開發(fā)、測試、實施、維護），各個服務(wù)開發(fā)小組靈活地游離于各個項目之間，每個項目必須配備一個項目經(jīng)理，一個項目經(jīng)理可以同時管控多個項目，就像一個服務(wù)開發(fā)小組同時服務(wù)于多個項目。各個服務(wù)小組都有自己擅長的業(yè)務(wù)領(lǐng)域，隨著團隊經(jīng)驗的積累以及自我驅(qū)動，服務(wù)組件的沉淀就是一件水到渠成的事情。當然，這一切的前提都是基于我們統(tǒng)一的服務(wù)化思想，集中力量于同一焦點，把效能最大化。
簡法十二：服務(wù)化思想
服務(wù)化思想其實并不是什么新鮮事，它早已游離在我們的生活之中，因此會讓我們產(chǎn)生一種似曾相識的感覺，這也許就是事物的相通性，而這種相通性的本質(zhì)可能就是源于我們?nèi)诵陨钐幍哪骋环N共性。
轉(zhuǎn)眼間，十二一輪回，將近四年的服務(wù)化實踐經(jīng)歷堪比十二載，但初衷還在，只是簡單已不再是單純的簡單，更多地會是一份發(fā)自內(nèi)心從容的簡單。
