title: 微服务架构设计分析
date: 2019-04-09 12:00:00
categories: 架构分析
description: 微服务架构设计分析
1. 微服务简介
近年来，在软件开发领域关于微服务的讨论呈现出火爆的局面，越来越多的公司企业倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发，被认为是IT软件架构的未来方向，Martin Fowler也给微服务架构极高的评价；同时，反对之声也很强烈，持反对观点的人表示微服务增加了系统维护、部署的难度，导致一些功能模块或代码无法复用，同时微服务允许使用不同的语言和框架来开发各个系统模块，这又会增加系统集成与测试的难度，而且随着系统规模的日渐增长，微服务在一定程度上也会导致系统变得越来越复杂。尽管一些公司已经在生产系统中采用了微服务架构，并且取得了良好的效果；但更多公司还是处在观望的态度。
什么是微服务架构呢？简单说就是将一个完整的应用（单体应用）按照一定的拆分规则（后文讲述）拆分成多个不同的服务，每个服务都能独立地进行开发、部署、扩展。服务于服务之间通过注入RESTful api或其他方式调用。大家可以搜索到很多相关介绍和文章，本文暂不细表。在此推荐两个比较好的博客：
http://microservices.io/
2. 当前现状
- 旧有平台通用性不够全面，在项目集成过程中对原有系统业务侵入性高
- 缺乏对系统平台的用户基础权限、数据权限及数据字典等通用基础功能共性维护
- 平台侧的用户相关权限资源配置维护繁杂，不易集中管理
- 缺乏统一的WEB UI标准式封装，导致项目很多模块风格迥异
- 开发效率低，缺乏自动化生成策略
- 不支持多数据配置，导致项目很难进行读写的剥离
- 缺乏专业接口对接机制，接口制式多种，更无接口标准API文档，不利于客户端对接
- 缺乏统一的接口安全机制，可细化控制接口程度低，不利于数据安全
- 系统依旧采用传统的MVC架构，较为保守，横向扩展性差
- 各个模块之间高度集成，抗风险能力若
3. 特点
系统架构总体设计上体现模块化，每个模块都可以作为独立的个体，且独立运营，倾向于分布式、去中心化，以便于版本长期迭代。
- 使用灵活，可以整个使用，也可以只用其一个或几个部分
- 学习成本低，上手容易
- 核心功能的稳定性，且尽量少的第三方框架及包
- 应用架构的外延性、连续性，便于集成、复用
- 易于知识积累，真正做到越用越强
- 易于集群与水平扩展，能做到不间断提供服务
- 针对业务模块之间的关系进行解耦
- 无状态服务，对每次请求的服务器处理是没有影响的。可以使用负载均衡技术（需要解决Session同步问题），实现高可用
在大多数情况下，如果需要同步更新很多个服务则说明系统的耦合还不够低，当然我们也不可能完全避免耦合，它总是会出现在某些场景下。为此需要我们总结提炼一些抽象层将服务之间的交互定在契约上来避免复杂，提升灵活性。这就要求我们在一开始设计过程中就要有一种辨别能力，能够找到那些必须放在一起来做处理而不能拆解的功能。如果这些功能是值得放在一起的，那我们就可以将它独立成一个微服务，遵循高聚合的设计原因。
4. 原则
- 兼容开放式原则：兼容已有技术，避免对系统的颠覆式改造
- 先进性和灵活性原则：采用目前主流的先进的技术、方法，满足系统不断增加和调整的业务需求；通过修改流程的相关配置文件实现流程的发布或更新，缩减系统改造周期
- 实用性原则：系统应具有良好的用户界面，操作简单方便。充分考虑录入人员特点，使数据处理工作简单、方便、快捷，业务流程清晰，符合常规业务处理习惯；对于常用的信息查询操作，系统提供灵活多样的查询和统计检索方式，满足不同层次的用户需求
- 减法原则：从技术经理、技术骨干到开发人员，工作量范围与内容越来越少
- 高效、经济：自动组装、复用资产模块，由框架进行自动组装，避免大量的系统配置，同时避免相关参与者做重复的事情
- 约定优于配置：通过约定减少代码及配置量
5. 目标
构建基础框架，同时能够与已有的应用模块集成，实现在原有的业务上不断运行。
- 统一的信息整合平台，将现有的应用系统、资源进行整合，打破系统建设孤岛、向应用的产品化发展
- 及时、准确、客观的同互联网接规，为产品的多元化提供技术支持
- 架构支持可灵活定制、拓展，实现模块标准化、通用化，可根据业务需要，与新建立的业务系统有效集成
- 业务系统维护实现分布式管理，去中心化
- 实现用户统一的用户、角色权限、统一日志、运维监控集中管理
- 实现统一的信息展示
- 业务系统维护直观、操作简便、无需专门技术人员
除上述目标外，该系统从设计方面，应兼顾稳定性、操作性、扩展性、先进性、可维护性、安全性等重要原则，在稳定、安全的基础上可以随着业务的发展逐步扩展。
6. 总体架构设计
6.1. 业务架构
采用当前业界流行的微服务架构，遵循统一技术路线，架构设计注重层间的松耦合与层间的高内聚，通过对业务对象的抽象内聚，组件化服务模块，统一服务调用，考虑的拓展性、稳定性、复用性以及可配置性，降低了维护成本和开发成本，使得系统变得更轻量化，能够满足业务不断的变化带来的架构挑战。
以核心功能为基础、以公共平台为纽带、服务能力高度共享的分布式架构体系
- 系统架构新特性：微服务化、服务治理自动化，服务能力开放自动化；自动构建、自动发布，一键完成部署；灰度发布，系统升级，业务不间断；
- Cloud 中心：服务标准化共享，满足内部、外部交互，实现运营商自营业务及第三方业务便捷集成，丰富网络应用与业务生态；
- 能力中心：建立开放的能力体系，实现能力标准化封装及便捷的服务访问手段，支撑能力显性化管理；
- 策略中心：端到端的策略管理，结合用户的业务需求、状态和现状，自主分析与识别，智能的决策与策略下发；
- 编排中心：实现长短流程开通服务编排，能力编排；可将原子能力通过编排组成新的能力自动发布；
- 采集中心、监控中心：实现系统各类数据采集分析与监控，实时图形化感知系统运行状态。
6.2. 逻辑架构
待补充
6.3. 应用架构
系统的应用架构可以划分为三个层次，分别是组件层、服务层与应用层，其中组件层是系统业务对象的组件化抽象和最低粒度的组装，服务是对相关业务组件的集成与更高粒度的封装，服务面向具体的业务应用；提供标准的调用接口供具体的业务应用直接调用；应用层包括了本系统业务与管理层面需要实现的具体应用。
6.4. 数据架构
系统逻辑数据架构是对系统业务对象的逻辑分类，本系统涉及的逻辑数据对象包括业务数据、字典数据、管理类数据、定义类数据。
6.5. 数据层次划分
系统的数据层次可以划分为数据源层、缓冲层、基础层、应用层。
- 数据源层是系统的原始数据，包括字典数据、管理类数据和定义类数据；
- 缓冲层做为对数据库数据处理的有效补充，减少对数据库的直接操作请求，负责对字典数据、部分管理类数据和部分定义类数据进行内存的缓存存储，依据各个子系统的性能和业务的综合考虑来确定是否需要将数据库数据缓存到缓存层中；缓存层的数据在对应来源数据变更时实时更新。
- 基础数据层保留所有提交的历史业务数据，包括表单数据和流程流转的实例数据。
应用层为面向各功能模块提供统一的接口视图。
6.6. 技术架构
6.6.1. 分层设计
本系统软件架构设计采用松耦合、分层设计的原则， 主要分为前端门户层、服务层，其中服务层又业务处理层、数据访问层。
- 门户层指用户界面,是用户访问本系统的入口，主要采用JSP+CSS+JavaScript框架来实现；
- 服务层是本系统提供对外业务服务的功能。该层将服务接口和实现分离，实现松耦合。同时，服务层主要采用Rest Full协议来实现，
业务处理层是指公共业务处理组件，主要用来处理服务层所共有的业务处理规则、流程等内容。业务处理层采用普通的Java对象来实现；
数据访问层是指提供对数据库数据访问的接口，被业务处理层或服务层直接调用。数据访问层主要通过系统技术平台的Spring JPA 和MyBatis来实现；
- 公共组件指按照规范统一实现的公共组件，包括用户管理、组织机构管理、权限管理、日志管理等模块；
- 事务处理指事务的处理机制，事务开始于服务层，采用数据库的事务管理器对服务层的相关服务进行事务控制处理。
6.6.2. 逻辑技术架构
系统逻辑技术架构包括四个层次：分别是用户层、访问控制层、应用服务层和数据存储层。访问控制层包括了网络的物理隔离设备与Web服务器，是系统访问和请求转发的第
一层。应用服务层是业务处理中心，负责对用户提交的操作请求进行业务处理。数据存储层包括共享存储设备、数据库和相应的数据备份设备。
- 利用成熟的开源框架，重新构建项目，对业务进行垂直、精细拆分，通过注册中心、API Gateway，对外提供可供服务，最终到达基本功能微服务构建
- 利用Shiro安全框架，构建授权、会话管理
- 前端强调页面表现，如：响应速度流畅，客户端兼容性强，用户体验等
- 后端强调高并发，高可用，高性能，安全，存储，业务等等
- 完成消息中间件的构建
技术架构：从技术层面描述，主要是分层模型，例如持久层、数据层、逻辑层、应用层、表现层等，然后每层使用什么技术框架，例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等，分别说明，要求这些技术能够将整个系统的主要实现概括。
应用架构：主要考虑部署，例如你不同的应用如何分别部署，如何支持灵活扩展、大并发量、安全性等，需要画出物理网络部署图。按照应用进行划分的话，还需要考虑是否支持分布式SOA。
技术架构关注的是：技术的分层及描述（不单纯只写mvc），关键技术的方案（如事务处理、缓存与集群等）
应用架构关注的是：应用功能的划分、应用功能集成和应用功能部署。
