本篇是通用服务平台总体架构设计第二篇，继续上篇尚未完成的模块构件功能应用简介。
6. 数据子系统
提到后端服务，就绕不开一个核心关键词--数据。不管什么样的业务系统，大规模、小型、简单业务、复杂业务基本最后都是围绕数据部分而展开，所有业务逻辑操作都将体现在数据层面上，在数据这个关键部分收尾。后端服务设计时常需要考虑的问题是从哪里拿到业务数据？修改后的数据如何存储？如何通知业务服务修改后的数据？等等诸如此类和数据相关的问题。同样通用平台虽然被设计为与具体业务无关，但依然有维持平台自身正常运转的必要数据，也一样要面对数据存储、访问、分发等若干问题。正是基于以上关于数据所需要面对的问题，使得我深入思考通用平台如何处理解决该类问题，同时解决方案能否达到通用目的。数据子系统就是在该背景下被设计出来解决此问题的较佳方案。该子系统以机房为单位进行部署，旨在解决非格式化数据的托管存储、常用数据操作及数据分发功能。同时该部分功能对第三方也开放，既其他业务系统也可以使用该数据子系统进行业务数据处理。该子系统在通用平台中承担着重要职责，目前设计系统内所有数据均由该子系统进行维护，不再由专有的数据服务存储维护，该子系统和前面所述的系统数据发布服务相结合，完成系统数据的存储、维护和分发。该子系统可以看成简化版的分布式云存储体系，设计适合多点存取，并借助该子系统解决大部分业务体系都需要的数据维护问题。该子系统的设计详见相关篇章。
7. 通信子系统
本人所维护过的后端服务中，基本都是服务之间直连。该方法好处在于无中间节点延迟较低，同时由于直连在链接断开处理上比较简单。虽然有以上诸多好处，但有利就有弊，服务直连就意味着服务需要进行链接服务数据同步，同时也需要维护链接，当对方规模较大，且需要链接多个时，弊端就慢慢显现。例如代理服务，就可能存在该种情况，因为代理需要链接后端多个业务服务，既要同步数据还要维护链接，拉低了代理的处理性能。那么是不是有更好的解决方案呢？答案是肯定的，本通用平台设计引用通信子系统，专门解决服务间通信问题。所有服务都链接至通信子系统中，由通信子系统根据数据包给出的目标服务来完成数据的发送。如此处理就能将服务间的N条通信链路收纳为数量较少的几条通向通信子系统的链路。同样，通信子系统也是以机房为单位进行部署，在进行数据转发时会判断目标接收方是否为本机房，如是本机房则直接转发，如不是本机房则跨机房转发。通信子系统屏蔽了服务间直连弊端可以使得业务服务进一步简化逻辑。当然引入该子系统后，同样也有弊端，既基于链路断开的一些处理将会出现问题，因为不是直连，所以无法侦测链路断开及时作出相关处理。该子系统的设计详见相关篇章。
8. 日志捕捉子系统
日志捕捉是一个常用的重要获取服务运行信息手段，通过数据配置，能灵活控制终端获取指定服务日志，不管是实时查看还是事后分析都需要该子系统支持。该系统主要由捕捉数据发布、捕捉终端、日志写入三部分组成。通用平台考虑各业务线差异，采用非侵入方式进行日志捕捉，被捕捉方毫无感知，实现灵活。该子系统的设计详见相关篇章。
9. 运维子系统
运维子系统是通用平台一个强有力的辅助系统，实现通用系统中所有服务的升级和配置文件修改功能。有了该子系统面对大规模服务升级和部署时，无需人工手动进行，仅需要在子系统中修改相关配置，运维子系统会自动进行服务升级相关操作，完成升级功能。可以节省大量人力和时间。该子系统的设计详见相关篇章。
10. 应急仲裁处理
应急仲裁处理是通用平台自动化，智能化的一个重要模块构件，正是它的存在促进完善了通用平台向生态系统演化迈出最重要一步。应急仲裁处理功用是通过收集平台各个服务实时运行信息，在该基础上，对运行信息进行综合分析判断系统当前是否处于非正常状态，是否存在潜在风险，通过预定义仲裁后如得出系统处于非正常状态，那么将触发一系列预定义操作，如某类服务过载，则采用自动添加服务方式进行扩容；如某服务所在机器出现问题，则采用自动移机方式将在其他机器上重建该服务；等等诸如此类会危及系统非正常工作问题，通过应急仲裁处理后，在非极端情况下，系统能自动智能化调节自身使得系统能在非人工干预情况下自动恢复正常运行，大大提高系统健壮性。
通过两篇简单介绍通用平台组成模块构件的基本功能，我们大致知道了通用平台能提供哪些系统基础功能，简单梳理总结下以免有遗漏。
一、提供地址分发功能，使得客户端能获取所有需要的服务数据。
二、提供通用代理服务，具备单点数据、群发数据、指定链路处理、自适应智能路由能力，能同时兼容各个不同业务线。
三、提供单点消息处理、群组消息处理功能。
四、提供非格式化数据托管、存储、操作、分发功能。
五、提供服务间非直连通信。
六、提供可配置服务运行日志捕捉功能。
七、提供服务升级、配置文件修改便捷功能。
八、提供系统应急处理功能。（各业务线可定制化仲裁，也能托管仲裁实现）
综所上述，通用平台能提供数种基础模块构件，有基础性的通信子系统和数据子系统，也有强功能性的日志捕捉子系统和运维子系统，这些基础模块构件都是在长期后端服务维护过程中，慢慢积累总结出来的个人想法。肯定有不足之处，甚至存在错误的观点，各位同行在浏览本系列设计时发现问题，请及时联系我改正，如果有兴趣一起讨论、一起致力于建设通用平台、一起共同进步。后续会持续推出各个模块构件相对详细些的设计，各位同行如有兴趣，请持续关注。
通用服务平台之总体架构设计（一）
通用代理服务设计
通用地址分发设计
系统数据发布
消息处理子系统
数据子系统
通信子系统
日志子系统
运维子系统
应急仲裁处理
