注
前期管理
投资控制
权限控制
报表引擎
进度管理
综合管理
流程引擎
数据分析
册
科研管理
材料管理
短信服务
邮件服务
中
政务公开管理
心
服务间同步
消息服务
数据访问层
MyCat数据库分片
MySql
MySql
MySql
Redis集群
Redis
Redis
Redis
32服务拆分原则
1、粒度微小：根据业务功能划分服务粒度，总的原则是服务内部高内聚，服务之间低耦合。
2、责任单一：每个服务只做一件事，即单一职责原则。
3、隔离性原则：每个服务相互隔离，且不互相影响

f
4、业务无关优先原则：基础服务，是一些基础组件，与具体的业务无关。比如：短信服务、邮件服务。这
里的服务最容易划分出来做微服务，也是我们第一优先级分离出来的服务。
33服务规划
为实现负载均衡，允许相同的服务在多个节点注册相同的服务名，不同的端口。如果没有前期的规划，不同的服务提供者可能会注册相同的服务名，导致消费者调用服务时产生调用混乱。
因此，需进行服务名的统一规划：1、规划期统一制定每个服务提供者的服务名或者模块标示。2、服务名的命名规则ModuleName_ServiceName，且所有字符小写，不同单词之间以下划线分隔。如用户管理模块提供了获取用户信息的服务，则命名为：user_get_i
fo。3、新增服务名时，需要提出申请，审批通过后方可使用，为减少审批复杂度，可只审批ModuleName，即在模块内部可以自由增加服务名，不需要进行审批。
34开发策略
总体原则：不同的微服务需进行物理隔离。1、编译策略：代码编译时，各个微服务独立编译、打包，杜绝直接的依赖；2、工程构建：代码开发时，各微服务创建独立的工程，工程之间不能产生直接依赖3、持续集成：每个微服务独立执行持续集成。
35数据库设计原则
每个微服务都有自己独立的数据库，那么后台管理的联合查询会非常困难。目前通用有四种处理方案。
1）严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标准的用法，也是最麻烦的用法。
2将业务高度相关的表放到一个库中，将业务关系不是很紧密的表严格按照微服务模

f
式来拆分，这样既可以使用微服务，也避免了数据库分散导致后台系统统计功能难以实现，是一个折中的方案。
3）MySQLMHA高可用架构、MySQL分布式Proxy水平扩展架构、MySQL缓存高并发读架构、MySQL小文件系统大字段存取架构、MySQLI
forbrightGree
plum统计分析架构。
4）数据库严格按照微服务的要求来切分r