业务支撑系统的核心骨架

拥抱变化，即将开始一个从0到1的新项目。简单思考了下总体技术架构的方向，恍然意识到一个事实：在现有的技术体系下，构建一个业务支撑类的系统最终所包含的核心技术组件其实都是一样一样儿的。

不管是电信运营商的业务支撑，还是电商的交易系统，又或者是物流行业的仓储或配送等系统，本质都是为了管理业务订单的全生命周期，区别在于不同的行业领域，在驱动业务订单的状态扭转时，其所承载触发的业务规则不一样而已。在系统建设期间，业支类系统面临的纯技术问题基本一致，数据读写、流程驱动、业务流转、能力抽象、服务暴露等等。所以总体层面上，架构师在做系统架构设计时所面对的技术问题也都是相似的。关键的架构设计问题在于如何结合系统建设目标，梳理整合好这些组件，使得系统在支撑业务流畅扭转的同时，还能够足够的高效，同时具备可拓展性、可复用等等。

上面这张图大致列出了当前我们在构建业支类系统时所要解决的技术问题，基本按照订单数据扭转的节点做了粗糙的分层，必定不完整，只求表达出大概含义。

一、终端层

任何一个系统粗略来讲，也是遵循冯·诺依曼体系结构的，终端层就是系统输入的来源，同时也是系统输出的目标端。为了增强系统更好的体验，在终端层也是需要优化考虑N多问题的，包括跨浏览器的友好支持、界面美观易用、打印控件、播放控件等等。

二、接入层

系统的网关，真正的大门，数据的输入输出均需要依赖接入层支持。一个最简单的接入层可能只是一个http servlet，但是健全的接入层除了保障数据高效、安全、稳定的输入输出之外，还应该最大限度的隔离本系统与外部系统之间的依赖。所以接入层需要面对的问题除了包括图中的协议、安全等内容外，可能还要解决数据映射、服务路由等问题，以实现隔离后端业务与其他前端接入系统差异的问题，保障系统后端业务的健康成长。

三、驱动层

基于各种引擎、底层工具等，灵活拼装起下层的服务，驱动业务流程的扭转。系统的柔性、灵活性主要就是体现在这一层，针对差异化的业务场景，能够灵活支撑，并且能够很方便的适应业务变化，灵活变更流程。

四、服务层

这一层负责承载真实的业务逻辑，需要考虑的是如何实现高内聚，高复用。管控不到位，可能会出现同样一种业务逻辑散落在多处，最后牵一发而动全身，系统就像被千万条丝带缠住双脚，动弹不得。

五、模型层

针对业务场景的领域建模和抽象。

六、存储层

数据库的分库分表隔离租户数据，分布式缓存提升性能，HBase做大数据量的存储，多机房数据同步、容灾等等。

七、分析层

运行期数据沉淀，离线分析，报表等。

这世间唯一不变的就是变化。随着业务发展，系统不断迭代建设，系统承载的服务能力不断增加。如果建设初期即能够一定程度上实现技术框架和业务逻辑的解耦，在未来必然会省了不少麻烦：技术框架的升级不会过多影响线上业务，真正做到平滑升级。同时业务的迭代也不依赖技术框架，相互作用又相互隔离，美哉！

继续发展，继续变化。底层框架的性能和拓展性已经都不是问题，但是系统越来越多，系统之间的交互也越来越复杂，耦合越来越紧。同时因为很多业务逻辑都是通过硬编码的方式存在，最后可能造成的局面是，随着维护人员的更新，最后没有一个人能够讲清楚系统的细节。；一个接口需求过来，没有人能确定现在的系统中是否已经有这个接口。系统的能力因为没有被管理，而导致极大的不安全、不确定。这应该是业务系统持续发展到最后不得不面临的一个问题：资产化管理。

从0到1建设一个系统，初期实现业务支撑目标并不难，难的是后续业务发展变化带来的对系统在拓展性、抽象、高性能等方面的持续要求，所以在建设初期，合理划分边界、增强组件弹性、系统柔性等方面就尤为重要。