大项目微服务架构设计

根据目前产品存在的问题，针对快速开发、海量用户、大量数据、低延迟等互联网应用的实际需要，通过对业务架构、系统架构、基础架构、技术架构进行分析，采用先进实用的微服务SOA架构重构智慧校园、数字化校园等产品，彻底解决系统解耦、性能低下等问题，而且支持云计算部署，可以满足高并发、高可用、高稳定和高安全等性能要求，提供强大的saas和互联网访问服务。由于采用微服务架构，各个服务模块化编写，具有高内聚低耦合的优势，便于灵活更新升级，而不会影响其他业务。一套代码，同时支持移动应用和pc应用，提高效率，节约成本。这个架构还便于AB灰度发布产品，提高开发效率，对测试、运维管理也可以显著提高效率。微服务通过REST方式提供访问,产品实现重构，进行服务划分，可以充分使用现有的代码。.NET产品使用ASP.NETWeb
Api提供rest服务，使用RestSharp访问服务；java产品使用restEasy提供rest服务，使用httpClient访问服务。服务实现统一的注册、治理、发现，通过serviceAdapter统一调用。这个架构有助于对外提供访问API，提供open的开发支持，有利于形成公司的产品优势。



 

这是一个非中心化微服务架构，互联网时代，企业的核心就是效率。传统企业服务总线是中心化的架构，这会导致效率低下、稳定性差，采用去中心化架构，教育显著提高效率，增强安全性和稳定性。采用数据库存储服务信息，采用消息队列处理事务，特点在于多次调用服务，确保成功，采用统一的接口调用服务，对服务进行管理。

 

这个架构为用户提供的一个核心价值，在于随着系统机器数量的不断增加，处理性能呈线性上升，可靠性呈指数级上升，而运营成本不会随着机器的增加而显著增加。为了实现这个价值，企业级互联网架构呈现了服务化、去中心化、异步化、高可用、数据化运营等五大特征。而且对于开发可以提高效率，产品修改设计方便，测试、运维简单。

服务化的技术体系提供企业级分布式应用框架来实现原有业务面向互联网服务化改造，改变现在的竖井式、烟囱式的系统建设，让应用开发周期更短，并且能够让IT应用系统进一步的促进业务发展。采用去中心化架构，没有核心流量汇入点，这样带来的负载更小，故障影响的范围也更小，能够大幅降低去中心化应用系统的运营成本。

2.1.1目前现状

1)没有服务化，各产品系统独立开发，代码复用率低，系统之间互相调用，耦合严重，系统解耦独立部署困难。

2)应用间数据复制严重，数据不一致性严重

3)基础组件薄弱，日志，监控系统不完善

4)功能模块定义混乱，包含大量接口，接口定义重复

5)大容量访问下无法提供可靠性服务

6)开发saas互联网功能的产品迫在眉睫，需要满足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。

2.1.2亟待解决

1)核心系统全面服务化：招生、教务、学籍、资产等系统分解为核心服务和基础服务。

2)基础组件：服务化框架，分库分区，缓存组件。

3)加强监控，日志系统。

4)异步化并行，限流，分流，降级，压力测试，异地灾备。

5)数据库统一规划优化。

6)平台和业务功能设计，遵从三个维度定义架构设计的原则：

a. 内容可扩展性

针对智慧校园各个功能提供动态支持。

针对梦想学堂营销活动提供动态可支持性。

b. 功能可扩展性

针对各种扩展功能需求，系统支持统一的方式扩展新的能力，并提供统一的管理。

c. 系统可扩展性

支持对大量用户访问能力的平滑支持。

支持高可用，高安全，并具有高的系统恢复能力。

以基于“云”模式的服务端IT架构框架为整体策略，采用基础架构和功能实现分离的原则：

a. 服务端：构建统一的云模式IT基础设施

基于标准化的设施，分别构建统一的IAAS层和PAAS、SAAS层，实现资源的共享，提高未来业务应用开发的效率和可维护性，并提高整体设备的利用

b. 大架构模式：实现基础架构和功能实现分离原则

功能开发团队

采用简单工具

关注流程

关注功能实现

关注服务划分和治理

关注数据处理

关注用户体验

系统开发团队

关注系统稳定性

关注系统性能

关注系统扩展性

关注系统可维护性

关注系统可靠性

2.1.3改进办法

（1）核心业务抽取出来，作为独立的服务对外服务，实现架构和代码重构。

（2）核心服务调用基础服务，充分复用代码，减少工作量，便于修改维护，把握好服务的粒度划分，过多的服务访问会影响性能，过少会影响灵活性，需要对业务进行细致梳理，合理确定核心服务和基础服务。

（3）服务模块独立部署，充分解耦，各系统灵活使用不同服务，可以独立部署，彻底解决系统耦合不能单独销售问题。

（4）各层彼此独立，修改各层不影响其他层。

（5）数据库读写分离、分库分区

（6）大量使用缓存，提高访问

（7）系统间异步交互

（8）服务对等隔离

（9）移动和pc产品的优化

APP实际上和PC端浏览器是对等的，PC端应用有服务端，APP也需要自己独立的服务端，两个服务端都需要针对自身的特点，独立开发，独立部署，同时实现逻辑和物理层面的解耦，从架构层面彻底摆脱PC思维移动化。

1. 统一服务

核心逻辑从Web应用剥离出来，进行服务化改造，服务实现时不区分PC和移动，APP和Web应用都依赖于这些服务，一套接口，多方调用。

2. 统一网关入口

提供统一的移动网关，所有APP调用指向此网关，网关包括通用层、接口路由层、适配层。

3.通用层

通讯协议适配、数据封装、安全、监控、日志这些系统级功能，每个接口调用都需要同样逻辑，这些功能统一由网关前置处理，避免重复开发。具体实现时，每个通用处理逻辑封装成拦截器，遵循统一的过滤接口，并且做到可配置，网关依次调用这些拦截器，这样可以支持通用逻辑的灵活扩展。

拦截器接口定义如下：

Object filter(Object input) throws Exception

接口路由

经过通用逻辑预处理后，移动接口请求将进一步分发给后端处理（各个Adapter）。URL和Adapter在配置文件里做映射，分发逻辑根据请求中的URL信息，找到对应的Adapter，然后把请求交给Adapter处理。

配置例子如下：

www.Website.com/search SearchAdapter

www.Website.com/detail DetailAdapter

4.服务适配

外部移动接口和内部SOA接口的输入输出格式以及通信协议很可能不一样，比如前者经常是HTTP+JSON格式，后者可能是Hessian+二进制格式，Adapter首先用于移动接口和内部SOA接口的适配，除此之外，Adapter还可能对多个SOA服务做聚合，对APP提供粗粒度的数据，以减少远程网络调用次数。实现上一般每个业务系统有一个Adapter，负责本系统移动接口的调用适配。

Adapter接口定义如下：

Object adapter(Object input) throws Exception

Adapter物理上是jar包，由各个业务线研发团队提供，作为相应SOA服务的前置，最终所有Adapter集中部署在网关，网关本身支持水平扩展。

（10）关键点：

1.服务注册中心，zookeeper集群作为分布式调度中心，各个服务注册在zookeeper之上，注册内容包括服务的请求url，请求ip地址和端口，服务组件名称，注册时间等；

2.Gateway，服务网关作为系统的入口，具有服务转发、授权验证、负载均衡等作用，可以使用高并发框架netty实现高速转发等；

3.访问控制服务，用户首先需要获得系统授权才可以访问业务服务，授权通过token来实现；

4.业务服务1~N，是系统内具体业务组件的划分区别核心服务和基础服务；

5.数据服务，实现信息的修改、共享等；

6.配置中心，整个系统的配置均位于配置中心，组件通过访问配置中心获取配置参数；

7.监控系统，检测服务、redis、zookeeper集群等的各项状态，自动告警和智能调节服务，防止服务器雪崩；

8. 消息队列系统，支撑全部系统；

9.服务治理、发现、调用。

10.服务调用通过serviceAdapter接口完成。

2.2关键功能

1. 通过重构智慧校园架构，完成原有功能及新增功能。架构分为应用层、核心服务层、基础服务层、资源层及ecloud层。

2. 应用层主要实现与Web页面、移动客户端的接口交互。

3. 服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为基础服务，定义是不依赖任何其他服务的服务模块，表示它们的独立性，另外一类为核心服务，通过各种原子服务和业务逻辑的组合，完成的Composite服务，定义统一的接口规范访问。

4. 资源层主要是数据和文件的存储，包含通用的缓存资源Redis以及持久化数据库存储MySQL、HBase，及分布式文件系统TFS等。

5. 水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。

6.Ecloud层提供一门户、单点登录、用户权限管理中心、统一数据中心、统一认证中心、运维管理中心、消息推送中心、配置管理中心、统一注册及验证、统一注销、报表服务、统一会话、元数据、日志、缓存及通用基础功能等功能。产品的上层服务层调用ecloud的功能，统一代码，充分复用，便于修改。

2.3关键质量属性

l系统中需要同时满足移动端产品以及pc产品的需求。

l 系统需要支持高性能、高并发性、高可用性的设计实现方案。

l 安全性：应保证系统中关键敏感信息的安全性，包括但不限于用户名密码凭证、Ticket信息等。

l 支持5千万人在线，大部分页面同时最多5000个并发请求，事务成功率不低于98%。

l 系统保证7*24 小时运行，稳定可靠；

l 平均延时：普通页面，小于2秒，最大不超过5秒；查询页面，小于3秒，最大不超过17秒；

l 支持负载均衡、可扩展性。

l 运维自动化，实时监控系统，及时发现异常和故障并自动告警。

l 系统故障恢复时间不超过1小时。

2.4平台价值

这个基础平台以先进的教育教学理念和技术作为依撑，以“应用导向”为基本原则，以探究教育教学的本质为主要精神，以教学资源整合为重要手段，以教学资源的开放共享为扩展方向，实现教育教学与IT技术的深度融合，采用微服务架构实现一个共享可复用的统一框架，是具有扩展性、兼容性、前瞻性的底层平台，实现6大产品共享，满足快速开发、避免重复开发的需求，开创产品创新的新模式和新途径，更好的为产品开发和部署、运维提供服务。

l 平台共享数据为各个子系统共同调用的数据，减少各子系统间数据的调用，减少系统间的耦合性，达到“强内聚，低耦合”的效果；

l 可实现数据一次输入，多个子系统使用，消除信息孤岛，减少数据库服务器工作量，提高整体使用性能；

l 提供统一的开发框架，提高开发效率，避免重复开发，节约成本；

l 便于部署，实施和运维；

l 整合6大平台，形成强大的合力。

l 形成一个产品，用于教育、金融等产品的开发和管理。

l 服务模块化设计，便于根据需求组合使用。

l 服务统一注册、发现、治理。

l 便于集群部署和负载均衡，提供强大的并发支持和高可用。

2.5约束条件

a)系统稳定、高效，可支持校园内外各种不同使用场景下的并发操作。

b)系统有良好的扩展性：在增加新的功能时旧有模块不做改动或稍作改动即可完成集成，部署更新不影响其他业务。

c)提供数据接口：便于其他产品或第三方厂商系统进行集成。

d)模块化：各个功能部分按模块开发，模块彼此解耦。

e)配置化：可根据客户实际需求，配置不同参数。

f）支持6大平台的开发和运行，支持Windows和Linux系统。

g） 采用B/S架构，与外部业务系统之间使用RestfulAPI进行交互，使用Spring MVC、java、c#语言进行开发。

h)需要支持高性能、高并发、高可用和高稳定的需求。

2.6信息标准

信息标准建设是数字化校园建设的重点之一，对推进数字化校园建设，保证 信息的交流与共享，有着重要的意义。鉴于各个学校的特殊性，因此所采用的信息标准必须保证和国家以及教育部的信息标准相兼容。

《教育管理信息化标准》的颁布为教育部门进行教育数据总体的规划和组织，建立统一的数据平台提供明确的规范和标准，它将带动教育管理信息存储、访问、更新、传递方式的变革，进一步减轻学校人力资源和财政管理的负担。

根据上述信息标准的要求，本公司将结合国家和行业标准以及学校的实际要求，制定出《学校信息化数据标准》。该数据标准在全校范围内作为数据编码的依据和标准，为数据库设计提供了类似数据字典的作用，为信息交换、资源共享提供了基础性条件。

标准制定的实施过程如下图所示：

 

制定完成后的高校信息标准有以下内容，如图所示：

 

1.
架构设计原则

3.1架构设计对后续工作的要求

l 系统采用B/S架构，需要使用spring MVC、java、c#语言进行开发，提供RestfulAPI和其他系统进行集成和交互。

l java系统采用java技术构建，应用服务器仅支持部署在Windows +tomcat8平台，但并不限定使用Ecloud系统服务的其他相关系统的操作系统平台,.net系统使用c#开发。

l 系统功能需要支持高性能、高并发性、高可用性的方案。

3.2架构设计原则

l SRP（Single Responseble Principle）即单一职责原则，每一个服务提供者仅暴露自己职责范围内的接口，操作职责范围内的DB，不继承其他服务提供者的协议。简单点说，该你干的才去干，不该干的调用其他人的服务来干。

lRESTful，作为Web Service的替代者，其面向资源的特性注定是为微服务而生的，接口设计符合REST设计原则将使服务易于理解和接受。需要注意的是，灵活的使用，如保持请求风格一致，一般用GET/POST，少用DELETE/PUT，保证同类资源前缀的一致性等。

l 分离关注点，将应用划分为在功能上尽可能不重复的功能点。主要的参考因素就是最小化交互，高内聚、低耦合。但是，错误的分离功能边界，可能会导致功能之间的高耦合性和复杂性，

l 最小知识原则，一个组件或者是对象不应该知道其他组件或者对象的内部实现细节。

l 不要重复你自己，你只需要在一个地方描述目的。例如，特殊的功能只能在一个组件中实现，在其他的组件中不应该有副本。

l 最小化预先设计，只设计必须的内容。在一些情况，你可能需要预先设计一些内容。另外一些情况，尤其对于敏捷开发，你可以避免设计过度。如果你的应用需求是不清晰的，最好不要做大量的预先设计。

l 高内聚低耦合：将不同的功能代码分离开来，更利于系统的设计和开发，同时为可能的变更提供了更小的单元，十分有利于系统的维护和扩展。新增的自定义公式必须符合该原则。

l 可视作一个独立的系统，为减少重复的开发、统一管理，提高整体开发效率而存在。

1、开放性

基础平台应具有良好的开放性和兼容性，采用面向服务的公共管理平台，提供REST API接口，通过统一信息门户、统一权限管理和公共数据交换，整合、集成各类应用系统和各种信息资源，实现资源和平台的开放共享。

2、先进性

基础平台整体建设采用先进的理念和思想、成熟的技术与设计方法，符合当前潮流与未来发展趋势，以便跟上信息技术的发展，具有较强的生命力，具有长期使用价值。

3、易用性

基础平台建设的核心目的就是“易用”，须坚持易用的设计原则，紧紧围绕开发的实际需求，在满足产品要求的前提下，以尽可能少的投入，取得尽可能大的效益。

4、可靠性

基础平台支撑着整个系统的日常管理、教学、生活、科研、文化、服务、信息安全和资源建设等方方面面，必须具有高可靠性、高容错性和强大的数据处理能力，使用成熟的热备份技术和集群技术，以确保不间断运行、确保局部出错不影响整体、确保快速响应。

5、稳定性

基础平台必须具有良好的稳定性，保证持续运行时间长、故障间隔大、无故障时间长。

6、可扩展性

基础平台必须具有良好的可扩展性，对于校园管理模式的变化、管理体系的调整、业务流程的改变等，能够通过规则引擎简便配置即可快速适应变化，满足学院的需求。

7、易升级性

基础平台采用版本控制机制与更新包技术，能够简便快捷地完成整体或部分的版本升级。

8、易维护性

基础平台的用户包括部门的管理人员、工程师，必须坚持易维护的设计原则，确保结构清晰、界面友好、操作简单、维护方便。

9、安全性

构建全方位、多层次、完善的安全保障体系，通过安全制度建设和安全教育培训，在保证物理安全和网络安全的基础上，保证数据安全。根据基础架构及各个软件系统的设计要求，采取不同的安全策略与安全措施，保证系统安全。

10.保密性

基础平台通过身份认证、角色定义与权限分配，确保每个用户能且只能访问相应的信息资源与应用服务。

11．可管理性

基础平台具有高度可管理性，使得开发人员的开发简便快捷。

12． 逐步完善，平滑过渡

要根据现有的产品情况，逐步开发实施，平滑过渡。

13．遵照 SOA 的设计理念，建立松散耦合的集成与应用

14．可持续建设

平台在满足现在开发需求的同时，能够兼顾公司的发展现状，设计一套能够满足未来一段时间发展的标准，并且在全局建设过程中能够持续的升级、维护标准。

15．服务组件及中间件一体化、通用化。

2.
逻辑架构视图

 

系统采用4层微服务架构，分别是展示层、应用层、服务层、数据资源层。

4.1职责划分与职责确定

按照“高内聚，低耦合”的思想，将不同的功能代码分离开来，更利于系统的设计和开发，同时为可能的变更提供了更小的单元，十分有利于系统的维护和扩展。系统采用微服务架构，分5层，分别是分别是展示层、应用层、服务层、数据资源层、ecloud层。

4.2接口设计与协作机制

Ecloud系统中，管理系统的实现技术类似，通过各个分层之间的协作来实现增删改查。下图以角色管理的增加功能为例说明各个分层之间的协作机制。

1. 用户通过Management UI增加角色页面一个角色，Management UI调用应用层Role Business的Add方法，同时把接收到Model实体对象传递到过去。

2. RoleBusiness层调用核心服务层和基础服务层服务，同时把Model实体对象传递到过去，进行处理。

3. RoleID逐层返回给Management UI。

 

4.3重要设计包和端口

项目的包名和类名需要规范化，按照统一的约定完成。

名称	说明
com.xx.platform.cache	缓存组件包，包含缓存相关类。属于公司级的公共组件
com.xx.platform.common	Ecloud项目的公共功能类
com.xx.platform.dto	显示业务实体类
com.xx.platform.vo	持久化实体类
com.xx.platform.dao	数据访问层
com.xx.platform.service	服务逻辑层
com.xx.platform.controller	业务逻辑接口层组件，应用真实的业务逻辑类
com.xx.platform.exception	系统的异常类
com.xx.platform.interceptor	拦截器类
com.xx.platform.utils	系统的工具类
com.xx. platform.configuration	系统的配置类

1. Dao类分为接口XXDao和实现类XXDaoImpl及数据库映射文件XXDao.xml。

2.Service类分为接口XXService和实现类XXServiceImpl。Service分核心服务和基础服务。

3.Controller类继承基类BaseBiz。

4.Vo和Dto类继承基类BaseVO， Dto面向页面和业务处理，Vo面向持久化。

PageModel类为分页类。

5.前端页面采用freemarker生成html，简单高效。

6. Exception 类继承基类BaseException。

7.尽量减少端口，充分复用现有端口。

4.4开发运行及使用

采用java和.NET开发，部署在tomcat8和iis上，

Java产品使用先进实用稳定可靠的jdk1.8+spring4+mybtis3+jquery1.9.1+freemarker-2.3.21+mysql5.6框架。支持ie8+、firefox、chorme浏览器，使用restEasy提供REST服务；.NET产品使用visiostudio开发。

3.
物理架构视图

5.1物理拓扑

 

系统理想的网络部署图如上所示。需要说明的是：

1. 应用服务器、CAS服务器、service服务器、管理服务器、数据库服务器部署在一个局域网内部。

2. 数据库系统采用主从结构，保证高可用性。

3. CAS服务器负责单点登录功能，需要保证高可用性，因此至少需要部署包含两台服务器的集群。

4. 管理服务器作为部署Management UI的WEB服务器，通常情况下部署一台服务器即可。

5. 系统管理员、用户通过Internet与分别与管理服务器、应用服务器链接。

6. 为了提供数据访问的性能，需要部署缓存系统Redis。

7. 采用docker、k8s部署到容器，实现集群的自动负载均衡和管理，提高性能和稳定性，简化运维。

 

 

5.2软件到硬件的映射

l 应用服务器：运行业务系统。WindowsServer 2013、iis+tomcat8

l service服务器：运行服务系统。WindowsServer 2013、iis+tomcat8

l 管理服务器：运行管理系统。WindowsServer 2013、tomcat8

l 数据库服务器：运行数据库系统。Linux、MySQL5.6、Redis3。

l 缓存服务器：运行Redis系统。Linux、Redis3。

 

5.3优化部署
为了减少硬件的成本，可以把管理系统部署在应用服务器上，省去管理服务器。各个模块可以分别部署，便于灵活修改升级发布。Service服务器可以根据访问量进行集群和负载均衡。