准确的来说，1.0平台的单体应用架构没有互联网项目架构一说，传统的MVC开发模式，简单的小作坊操作流程，对于每个开发人员来说，只需要关注业务的功能模块实现而已。在1.0平台运营的半年时间里面，除了业务本身的需求爆炸性的增长，要求开发的迭代迅速，并且每次升级都不应该伤筋动骨，只是模块化的累加或者在原有的框架里面局部的更新，除了这些，我们还看到了1.0平台本身的基础性运营配套设施也迫切需要投入进来，以提高平台的运营效率，如日志平台，监控平台，调度平台，报表平台，甚至权限和单点登录也很需要，所以对于2.0平台的整体规划以上的都应该包含在里面。

一 平台整体能力规划

主要将一些公共的东西全部从原有的业务层里面拆离出来，以平台化软件包的模式运营。

1. 统一调度平台在项目中很多业务会经常用到，但是1.0平台将调度工作和业务执行工作全部糅合在代码里面，造成大量的调度工作后期的维护非常不便，而且调度没法监控目前在运行的调度和距离下次需要执行的调度。统一调度平台可以解决这方面的问题，可以有效的通过管理界面来维护平台的所有调度工作，从设计角度简单来说，调度的工作归调度平台，业务的执行归个各自业务平台（微服务）。

2.统一接口平台主要解决前端应用系统通过统一接口平台获取数据，不直接与外部系统接口打交道。统一接口平台通过多种方式与外部系统联接获取数据并向各前端应用系统提供各种数据格式包，将外部系统有效地隔离在业务系统之外。前端应用系统需要请求的外部接口需要在统一接口平台注册，开放。每次访问都会被有效的记录，实行监管。在前后端分离架构系统里面（其实微服务就是这种），统一接口平台也担当跨域，和负载均衡的职能在里面。

3.统一日志平台前期主要解决需要登录到linux服务器，开各种账号权限查看log日志的麻烦，可以让开发人员通过管理界面管理日志，查看日志，以提高工作效率，中后期会将ELK日志分析工作引入到平台。

4.统一权限平台主要针对众多的各种平台 （如上面的调度平台，接口平台，日志平台等）的权限统一管理，这块配合SSO单点登录一起使用，如果按照传统的每个平台分配一个账号，操作起来比较麻烦，统一权限平台+SSO单点登录就是解决分配一个账号，分配权限，可以进入各大平台操作。

5.统一消息平台主要针对内部业务系统的MQ中间件平台管理，和统一调度平台类似，业务的执行归业务，MQ只负责异步中转，可通过多种协议接入如http，接入更加坚定快捷，维护更加方便。

6. SSO单点登录，只需要登录一次就可以访问所有相互信任的应用系统，而不用重复登录。

更多的平台还在规划中，后面的文章也会一 一涉及到，并分享遇到的一些坑和做的一些优化。

二 业务领域拆分

2.0架构体系的业务拆分是个很头疼的事情，说实话，按照目前具体的项目团队情况和服务器规划，既不能拆的太细，也不能拆的太粗，只能按照阶段去拆去优化，所以我的打算是先按照业务功能稍微粗的来拆，等微服务框架平台整体流程稳定后，再针对每个业务功能细化拆分。

业务领域一旦拆分，意味着也要分库，由原来的单库拆分成多库。

从数据库架构上来说，考虑到服务器成本，前期还是单机高可用，后期再做分片集群。

三 服务化架构

前端请求到后端大概整体流程（具体以项目实际为准）:

1.访问html前端页面,(每个页面引入checkCookie.js)，如果cookie失效,跳转到sso单点登录页面。

2.sso认证用户和密码成功后，生成token写入redis和cookie。

3.sso跳转到需要访问的html前端页面，(每个页面引入checkAuth.js)，html前端页面请求(post请求)统一权限平台,权限平台通过从cookie中获取token，从token中获取用户信息，查询用户角色和资源菜单具体权限返回给html前端。

4.html前端根据当前用户角色拥有的具体资源菜单展示不同的div块显示(如果页面布局麻烦，也可以不改变原先页面，只是将没有权限div块内容屏蔽或者显示无权限查看)

5.html前端div块里面的内容展示，通过请求统一接口平台API接口，统一接口平台请求具体java业务平台API接口(微服务)，API网管拦截，验证token是否在redis存在并合法，如果合法放行，通过客户端负载均衡到具体微服务获取具体数据，返回html前端并展示。