互联网项目系统架构经验浅谈

一、如此架构设计构想的起因

1、“互联网+”这个概念之后，政府部门、民营企业等各行各业似乎忽然都“醒了”，每个单位都发现自己迫切需要建设各类信息化系统，“大数据分析系统”“云平台”等能建的都要建起来，似乎只有这样才能与总理的思想保持高度一致。总之托福了，互联网类的项目确实多了起来，但随之而来的问题是，我们自身的生产效率跟不上了，必须寻求改进的路子。

2、现在的客户志向都很远大，准备做个项目前从来都不考虑自身的实际情况、不考虑实际需求、更别说对自己的业务有明确的规划。反正开口闭口就是PC网页版、手机网页版、微信、app全渠道都要打通。让其描述一下自己所需要的功能细节，却什么都讲不出，等我们做了些功能出来让其试用时，各种奇葩的想法、需求、变更如点燃的烟花一样各种喷发。面对这样的客户，我们的系统架构要具备高效、灵活、支持多终端的特性。

3、“携程事件”促使我思考怎么去优化系统架构。公网线上系统，不容许出现整体宕机或者是某个业务长时间中断，因此系统架构需要冗余化、离散化、低耦合的方向改进以提高稳定性、可靠性。

二、UI层与业务层分离

在项目工作的划分和安排上，传统、原始的做法一般是把项目拆分成若干个子功能，分给各个组员，每个人都需要把数据存取到业务处理到页面呈现这整个过程都完成。久而久之这种安排的弊端逐渐显现：

1、这样的安排要求每个组员撑握的技术要全面，数据库操作的技术要强、业务要理解透、UI开发的能力要强、还要对付得了各种浏览器的兼容问题，但现实中这样全面发展的选手凤毛麟角，项目最终还是沦为了“水桶理论”的又一次实力验证，效果总是难以令人满意。

2、在做完PC网页版、手机网页版的系统之后，还需要再为app专门去写一套接口，又多一份工作量。

3、人力安排缺少灵活性，一个组内，有的组员能力强开发效率高，按排的功能很快就能开发完，而有的组员开发效率低，任务完成较慢，但高效率的组员完成任务之后，却发现，无法再调配低效率组员的任务给他，因为他对低效率组员负责的功能不了解。

由此促使我思考是否有更好的方式来拆分项目、安排任务。随着项目经验的积累，UI层与业务层分离的思路便逐渐产生:

UI层: 把PC网页、手机网页、微信、app都划归为UI层，俗称前端

业务层：把数据处理、业务处理统一归为业务层，俗称后端

定义统一的接口来连通UI层与业务层，如下图：

当UI层与业务层分离后，工作划分和任务安排将不再是把一个项目拆分成若干个子功能，每个人负责一个子功能了，而是，先根据需求设计页面样式、设计数据库表结构、定义出所有接口的API文档，而后，按接口来划分工作安排。这样做的好处是：

1、每个子功能都有一个或多个接口组成，这样一来在任务的分功上更加精细。

2、UI层的开发与业务层的开发可并行实施，可以缩短项目开发周期。

3、人力安排可以更合理，UI开发能力强的，负责UI层开发，后端代码能力强的负责业务层开发。

4、人力资源调配更灵活，项目开发都变为面向接口开发，有了定义好的接口文档，只需要按照文档要求来实现相应的接口即可，因此可以随时调配人力放到相应的接口开发上即可。

5、统一的业务接口，可支持多种终端。业务接口只需要开发一套，后续增加终端平台时，也只不过是增加UI层的开发而已，降低了开发成本。

三、如何来实现？

首先从系统结构上来讲，把整个系统划分为基础数据层、接口服务层和应用展现层，应用展现层与接口服务层的交互统一采用http请求与返回json格式数据的方式进行，如下图：

其次，接口服务层细化分解成各个提供特定服务的接口，此处以购物商城为例，分为了商品信息接口、订单管理接口、认证接口、活动接口等等。这样做的好处有以下几点：

1、避免系统整体宕机，在这种结构下，任何一个接口服务停止都不会导致整个系统都不能用，最多也就是该接口提供的服务不能用而已，与此同时，维护人员维护该接口时，也不会影响其他服务的使用。

2、接口更新、升版时，也互不干扰。

3、开发好一个接口就可以用一个接口，无需等待全部的都完成再使用

4、得益于接口与接口之间的低耦合，遇到客户需要变更或新需求时，随时新增一个或修改一个接口就可以解决，而不影项目整体。

5、每一个接口服务都是一个webapp，部署上也会更加灵活。可以完全根据服务器的性能，来决定如何部署。如下图所示：

四、如何运作？

以购物功能为例，实现一个购物功能的过程，其实就是调用多个接口的过程：

五、总结

UI层与业务层分离之后，使未来的项目开发都变为面向接口开发，可以提高开发效率减少开发周期，降低开发成本，专人专用，高效、灵活、支持多终端，通过优化部署提高系统稳定性。