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