记得14年初下定决心重构系统的那一刻 ，“一切从简”的欲望尤为强烈，只因事情已经被“复杂”堵得水泄不通，其实归根到底还是过往自身的工具化思维局限了问题“最优解”的选择。对于一个“入世未深”的小伙来说，“简单”仅仅是简单。但无论如何，能把“简法”付诸行动，就已经不很简单了。
简法一：为什么不把这坨该死的代码拆开？
每当代码打包发布的时候，一个上百兆的部署文件让我深感忧虑。我的担忧并非空穴来风，一次又一次的瓶颈让我验证了这该死的担忧。面对这样一个庞然怪物，就算无数个“通宵”也削减不了我对它的力不从心，“分解”成为了我当时的唯一想法。因为“分解”是我们人类处理复杂的一种常识化手段，它能让我把一条复杂的数学题逐一破解，也能让我把一项艰巨的任务分而治之，更让我看到了人类从“自给自足”到“专业化分工”的魅力。
简法二：除了MVC，我还能如何选择？
无可否认，MVC是互联网时代的“王者荣耀”，但随着移动互联网的发展，我试图寻找另一种更适合多端消费的服务化抽象模式。如果我只是单纯地把沉重的SSH切换到当时较为流行且轻量的SSM，其实并没有太多本质上的区别。我们当时的这种“服务化”分解其实更多地想给“消费者”提供一种轻量化、标准化、抽象化的服务支撑，如果要用专业术语来形容，可能SOA（面向服务架构）更为贴切。但ESB和WS作为当时SOA的主流实现和工具，它们的“沉重”让我望而却之。
简法三：继续找合适的“轮子”还是“自造”轮子？
有想法对于一个年轻人来说再正常不过，但把能把这想法付诸实现还是需要一定的付出、勇气和机遇。才疏学浅的我在当时并未看到“服务化”的普及，选择一款成熟且契合自己思路的工具也不是一件容易的事，又或许是我内心当时那份热血澎湃的重构欲望在日益膨胀。幸运的是，开放的平台给了我足够开放的心态、空间和信心去打造属于我们的“轮子”。
简法四：轮子的思考
“简单”是我们设计的首要原则，因为简单赋予了灵活，提高了效率、增强了可控，而且自主研发的约束范围也会远远大于工具的选择，为“简化”创造了无限可能。开源工具的思考边界可能更多地会集中在技术引擎和技术规范二者之间，因为它必须抽象在应用场景之下才能达到一定的通用性，所以开源的考虑会非常周到且功能齐全，但会存在一定的“臃肿”和“个性化”局限，这也是我们“自造轮子”的重要考虑之一，但更重要的还是从本质出发。
简法五：技术引擎的思考
“服务化”的设计理念会把应用根据“领域边界”分解成一个个独立的“服务进程”。其实，划分后的应用系统跟操作系统还是有几分相似之处，服务好比进程，线程好比服务的业务执行单元。事实上，它们在运行过程中就是这样一种上下层的对应关系。
线程的执行是基于栈帧的“跳进跳出”，而业务的执行是基于“流程”的线性执行。“流程”是业务执行的线性抽象，对“流程”的分解、定义、组织和管控恰恰就是我们对“技术引擎”设计的关键所在。
简法六：技术引擎的实现
对流程的抽象并非想说明我们“轮子”的独特之处，而是尝试对流程本质进行重新理解。因为本质，所以无论SSH还是SSM都能作为该抽象流程的一种实现。但是，我们要做的是尝试重新透过现象看本质，然后基于本质之上一砖一瓦重新打造出我们“服务化”理念的另一种实现。
一张白纸的背后可能隐藏着数十道工序的运作，我们“轮子”每砖瓦的堆砌同样少不了对系统从始至终、由里到外的无数次观察和思考。每一次的重构都千差万别，每一次的放弃都异常挣扎，但每一次都更接近于自己的内心。
除了服务交互协议层外（Service Interaction protocal），我们把框架总体划分为框架服务（Framework Service）、基础服务（Base Service）和业务服务（Business Service）三个层次，各层次服务都是由定时器模块组件（Timer）、初始化模块组件（Initor）、销毁模块组件（Destoryer）、业务前置模块组件（ SB_Module）、业务后置模块组件（SA_Module）以及业务实现模块组件（Services）组成。从结构上看，每一层的服务都内嵌于它上一层的服务之中，让各种模块组件形成了一种高约定、标准化、插拔式的切面规则。
从开发框架的切面结构上看，框架的规范化约束已经弱化了传统的三层结构模式，把一切非核心逻辑“边缘模块组件化”，重点关注业务的核心逻辑实现。
简法七：技术规范的定义
因“欲望”的驱动，“自由”成为人性放飞自我的向往，但无拘无束的“自由”往往会对人性的自我控制形成严峻的考验，否则不会“无规不成圆”。“自由”和“约束”看似一种鱼和熊掌的关系，实际上，“约束”是迈向“自由”必不可少的前提。所以，“约束”可以让我们尽量地减少了配置、封装和依赖，尽量以一种简洁、高效且通俗易懂的工具形态让执行者“自由地”聚焦在问题的本质之上。
以上的服务定义主要源于我们对技术引擎的流程抽象分析。但业务服务（BUSINESS）本身除了具备核心业务的能力支撑以外，背后还隐藏着一个对核心业务的管理职责（俗称服务信息管理平台）。因此，我们继续把服务按功能性类别分解为“面向服务支撑（SOP）”和“面向服务管理（SMP）”两大类服务类型，无论业务支撑还是信息管理都实现了前后端的分离，把轻量化SOA演绎得淋漓尽致。因为基础服务与业务服务的强关联性，基础服务同样被细分为BASESOP和BASESMP两大类基础服务。
服务目录命名规范中的xxx为业务服务自定义标识，模块组件命名规范中的XXX为三位纯数字组合，除了唯一性的约束以外，还具备了内部模块组件（除业务实现模块）执行顺序的规范化约束，这一点跟Linux的运行级别中的运行脚本命名规范还是有几分相似之处（KXX.../SXX...）。
简法八：应用规范的定义
从某个角度来看，人性的“懒惰”是社会进步的动力，它激发了人类创造的欲望来释放自己并减少一系列人为的不稳定性。但在那些尚未被工具自动化或智能化所覆盖的领域，适当的提前约束和规范同样是对人为管理的一种自动化体现。
框架的会话上下文（SessionContext）是线程流程代理及其模块组件解耦的关键所在，它承载着整个线程生命周期的状态信息，如业务会话（抽象）对象、请求报文对象（JSON）、响应报文对象（JSON）、模块组件内部执行上下文以及关系数据库事务控制等数据和信息。而框架服务内更多地集成了流程的一些应用规范化实现，如服务并发控制拦截，数据统一解析、安全拦截验证 、数据统一响应输出以及统一规范化日志记录等基础应用实现。此外，框架还集成了如关系数据库、内存数据库、远程过程调用等规范化的“数据适配器组件”，让业务的核心逻辑更加轻量和清晰地聚焦在业务层面（Service）。最终，应用服务基于标准化的应用规范之上实现了全方位的流程代理及管控。
简法九：服务网络
经济学认为“交换驱动发展”，这是人类从自给自足发展至全球化分工的一个演变“真理”。而互联网的出现更让交换出现了前所未有的低成本、大范围，甚至把数量庞大的“物”也“卷入”了交换的浪潮，把未来的一切想象无限放大。“服务化”应用同样是信息交换驱动发展的一种演变和趋势，一个个具有“独立领域行为”的个体服务在信息交互过程中增加了各种应用行为“涌现”的可能性。
服务发现中心（KingWorks-RDC）在服务网络中扮演了信息登记服务的角色，有点类似于DNS服务在互联网中的定位，“模糊”了主机的位置，解耦了服务之间的关联。归根到底，RDC是一个基于服务开发框架（KingWorks-SDF）建设的“动态解析”支撑类信息服务。而微网关（KingWorks-MSG）则是一个内置于服务开发框架的服务请求代理组件，除了具备基于RDC动态代理的实现，还兼顾了“静态解析”的预留，为一些“稳定”的服务应用场景省去了动态的消耗。
服务信息的动态解析是基于“服务信息中心”组件的周期更新，此外，RDC还预留了“服务变更”主动推送通知功能，需要此功能的服务只需要通过“推送开关”配置即可实现RDC的服务变更实时推送通知（非强一致性），提高本地服务对敏感信息更新的实时性。另外，对于一些存在多服务区域（多局域网）的应用场景，我们通过对本地服务信息（IP1&PORT1）和外部服务信息（IP2&PORT2）的区分让“混合云”的服务化应用成为可能。
简法十：自动化管控
凡事都有两面性，好坏优缺得失并存，但是善于“扬长补短”的人类注定不会让社会成为一个“零和游戏”。当我面对服务化多节点所导致的高额人工维护成本时，自动化工具将是这场“正值游戏”的重要手段。
自动化管控服务（KingWorks-OPS）是整个服务化应用的管控平台。底层主要是由一个C/S模式的脚本任务调度引擎支撑，C是一个内嵌于应用服务的任务执行代理（OPS-Agent By Python），提供了定时和实时的执行入口，而S则是一个任务调用管控服务，集中式对所有服务任务进行管理、配置以及调用。基于引擎之上的，就是面向场景的集成，如服务统一配置与管控、数据集中可视化监控、自动化告警处理以及自动化实施等场景的扩展。
简法十一：服务化协作
人的一生其实可以归纳为只是自己与大脑的一场游戏，行动受控于思想，且行为上变化更多是自身的潜在思维与受控思维的一场较量，就像我们应用从传统到服务化的转变无非就是一场“自我驱动”对“随波续流”发起的挑战。改变了思维，改变了技术，当然，也改变了我们团队的协作方式......
“DEV-TEAM”主要是由1个组长+2~3个组员组成的服务开发小组，基于开发框架的模式我们把小组主要划分为前端小组（Android、iOS、H5）以及服务端小组（设计、开发、测试、实施、维护），各个服务开发小组灵活地游离于各个项目之间，每个项目必须配备一个项目经理，一个项目经理可以同时管控多个项目，就像一个服务开发小组同时服务于多个项目。各个服务小组都有自己擅长的业务领域，随着团队经验的积累以及自我驱动，服务组件的沉淀就是一件水到渠成的事情。当然，这一切的前提都是基于我们统一的服务化思想，集中力量于同一焦点，把效能最大化。
简法十二：服务化思想
服务化思想其实并不是什么新鲜事，它早已游离在我们的生活之中，因此会让我们产生一种似曾相识的感觉，这也许就是事物的相通性，而这种相通性的本质可能就是源于我们人性深处的某一种共性。
转眼间，十二一轮回，将近四年的服务化实践经历堪比十二载，但初衷还在，只是简单已不再是单纯的简单，更多地会是一份发自内心从容的简单。