从事服务端开发多年，由开始的一无所知，到渐渐有点经验，到近年一直在想是不是可以搭建相对较为通用的服务平台，让业务方无需关注诸如通信，日志，系统数据等等细节，仅需专注自身业务即可，且该平台能被多个不同业务所共用，以便减少开发，提高构件复用性。以自己积累的经验来考虑通用平台需要提供那些基础功能、怎样将这些基础功能抽象出来作为通用构件复用、通用平台实现存在什么样的难点、通过怎样设计能提高系统扩展性和稳定性。经过近段时间的考虑沉淀，目前也有相对清闲时间，于是就有了通用服务平台设计系列博客。本篇是通用服务平台总结，概要设计工作逐步结束，接下来考虑逐个构件实现。
1. 通用平台定位
（一）为多业务体系提供通用平台。通用平台通过模块构件提供基础功能，使得其他业务体系无需再进行基础功能开发，可快速接入通用平台业务迅速上线。通用平台设计考虑能同时支持多个不同业务体系共享平台基础功能。
2. 通用平台提供功能
（一）通用代理。通用代理是平台必须提供的构建之一，是实现支持多业务体系的前提，该构件能屏蔽各业务体系协议差异统一了入口。
（二）系统地址分发。通用平台考虑各业务都需要一个对外分发系统服务数据的功能，所以由专门构件提供该功能。该功能保证各业务体系相互隔离。该功能是可选功能，各业务线可以使用自身服务，但如果系统数据出现调整，可能导致数据有误，影响客户端正常功能。建议使用通用平台提供功能。
（三）消息处理子系统。通用平台提供针对客户端非原路返回数据通路，既能提供单点客户端，也能提供群发客户端。当需要群发功能时，需要业务体系配合在代理上新建群发组才能实现群发。该构件也为可选构件。
（四）数据子系统。通用平台综合常见业务系统需求，为访问频繁、数据量不大且存储简单的数据提供云储存访问功能，且实现数据的订阅分发工作。该子系统融合数据存储和数据扩散分发功能，这是大多数业务系统常用功能，通用平台将该功能抽象成模块构件提高了复用性。且该子系统数据存储和同步都以机房为单位，节省带宽。该构件为可选构件。
（五）通信子系统。通用平台为解决常见业务系统中服务直连，当服务规模较大，相互之间链接较多，业务服务维护链路也较为复杂，不利于维护问题，提供一种松散型通信机制，既给出接收方key通信子系统代为传输模式，使得业务服务无需面对复杂链路维护，仅需维护到通信子系统链路即可，规范了通信，提高了可维护性，提升了业务服务性能。该构件通信以机房为单位，是可选构件。
（六）日志捕捉子系统。通用平台提供非侵入式日志抓取功能，可以进行关键字设定模糊匹配抓取，根据数据有效时间，分为临时和长效两类。各业务方可以配置属于自己的关键字，日志数据可以通过web后台进行浏览查看。一般的，临时数据用于在线调试和现场分析问题，长效数据用于纵向数据对比。
（七）运维子系统。运维子系统负责全平台运维工作，包括服务守护、升级、关闭和配置文件更新等功能。各业务线可以通过web后台发布运维任务，达到自身运维目的。
（八）应急仲裁处理。应急仲裁处理是日志捕捉子系统和数据子系统做为分析数据源，以运维子系统作为操作执行者，配合形成系统保护安全机构，实时监测系统运行状态，发现异常时采用预定义处理措施对系统进行调整，牵引系统回到正常运行状态。该构件目前只针对系统服务进行监测，各业务系统可以开发各自应急构件也能将服务设置为托管处理，由本构件监测。
综所上述，通用平台提供代理、系统地址分发、消息处理、数据子系统、通信子系统、日志子系统、运维子系统和应急仲裁处理这几大基础功能，基本涵盖了业务系统除业务逻辑服务以外的其他基础功能，有了这些基础功能，只要将业务逻辑服务接入平台既能应用，节省开发时间和成本，快速使业务上线。
3. 如何接入和使用
（一）客户端使用。可以提供针对系统地址分发构件和通用代理构件的通信库。将数据包和业务细节封装起来，客户端只需要传入适当参数即可快速使用接入本平台。
（二）服务端使用。同样封成通信库形式以便使用方无需关注协议细节和通信细节。对于需要自己实现的服务，也可以给出通信数据包，但不建议采用该解决方案。
本篇是通用服务平台阶段性总结，作为初步概要设计系列完成的一个标志，将自己对于通用平台的一些粗略设计简介给各位读者，希望各位读者都能有所收获。
通用服务平台之总体架构设计
