原文链接：https://blog.csdn.net/beyondself_77/article/details/79844785
微服务架构设计实践
目 次
1 序言
2 微服务
3 软件架构设计思想
4 微服务架构设计实践
4.1 项目概述
4.2 架构准备阶段
4.3 概念架构阶段
4.4 细化架构阶段
4.4.1 业务架构
4.4.2 数据架构
4.4.3 应用架构
4.4.4 技术架构
4.4.5 物理架构
4.4.6 开发架构
4.4.4 技术架构
4.4.4.1 技术架构定义
技术架构定义了实现整个系统所需的各种技术，包括开发类、过程管理类、运行环境类、运维支撑类、以及相关技术规范等。
更确切地说，技术架构描述了在一个可以独立部署的应用系统里，应用、应用平台、基础设施之间的关系。
在技术架构设计过程中，通常采用分层设计模式，把应用、平台、基础设施相对独立地拆分为以下几层：
1.系统层，也叫基础设施层，包括系统级的硬件、软件两层：
底层硬件包括主机、各种服务器、PC、存储设备、网络设备等；
第二层系统软件包括各种操作系统、数据库等；
2.平台层，通常包括两层，也可以混合成一层：
下层是中间件或技术平台。中间件通常指的是厂家在系统层的基础上提供的平台软件，例如IBM的WebSphere、BEA的Tuxedo等；技术平台通常指的是用户自己开发的平台软件；
第二层是基于中间件之上的开发框架与运行环境生成平台，包括各种生成环境与工具：如建模工具、可视化开发工具、第四代开发语言等；
3.应用层，包含所有的应用，处于整个技术架构框架的最上层。
针对不同风格的数据架构和应用架构设计，其实现所需的技术栈是不同的。
正如序言所述，分行特色业务云平台是分布式服务架构向微服务架构的演进，使用更细粒度的服务和一组设计准则来实现大规模的、复杂的系统设计，并非一个纯粹的微服务架构风格的项目。
为了项目后期能顺利地迁移到微服务架构，此次的软件开发完全按照微服务架构的标准进行技术标准的制定和技术选型。
在进行微服务架构设计过程中，主要从以下几个方面考虑：
4.4.4.2 技术架构设计原则
4.4.4.2.1 系统运行时原则
应用或服务在运行时，应该提供如下特征：
4.4.4.3 技术架构实践
分行特色业务云平台在实施过程中，由于项目进度、技术栈、研发团队等方面的约束，基础实施前期采用虚拟服务器集群，后期迁移到行方私有云，技术栈中的其它部分会根据具体情况有所微调，但基本不变。因此，在进行技术架构设计过程中，首先提供一个基于虚拟服务器集群的总体技术体系，然后再提供一个采用云部署的部署方案。
4.4.4.3.1 总体技术体系
分行特色业务云平台的总体技术体系包括在项目整个生命周期过程中，软件开发人员需要遵循的技术规范，所使用的开发工具，开发、运行、运维过程中的技术、以及贯穿整个软件生命周期的过程管理工具。
依据微服务架构的关注点，结合行方目标业务量、研发团队规模、已有技术平台、开发语言约束（Java）等因素，所以，分行特色业务云平台的Java技术栈的技术选型如下：
1.服务框架
选择Dubbo作为分布式服务框架，Tesla平台已经集成Dubbo；
Dubbo提供了高性能和透明化的RPC远程服务调用方案，以及服务治理方案；
2.运行时支撑服务
服务注册中心：采用Zookeeper作为服务注册中心；
服务网关：自主实现API网关，实现通讯协议解析，安全认证，流量控制，数据转换，协议转换等功能；
配置中心：自主实现基于DisConf的配置中心；
负载均衡：基于F5的硬负载，Dubbo提供的软负载等；
3.服务部署平台
支持灰度发布；
基于行方私有云的容器调度、租户资源治理；
半自动化的服务发布流程（后面详细描述）；
4.服务运行平台
第一阶段基于Linux虚拟机的集群部署；
后期迁移到私有云，基于docker容器集群部署；
5.服务安全
基于角色的认证授权机制；
引入数字证书，对通讯数据进行签名、验签，保证用户的身份认证、通讯信息的完整性；
通过数字签名和数字时间戳，保证业务操作的不可抵赖性；
6.服务容错
基于Dubbo实现服务的开关、限流、降级、超时等；
7.服务监控
基于Logback分级记录系统运行日志、业务操作日志，并定期同步到日志归档平台；
通过自定义Spring注解实现服务调用链日志记录；
集成到Tesla监控平台，实现分行特色业务云平台运行状态的监控；
8.后台服务
引入ZDAL，实现分布式数据访问层，支持分库分表；
基于Quartz自主实现自动任务调度；
自主实现本地内存缓存，采用Redis实现分布式数据缓存；
综合以上内容，分行特色业务云平台的总体技术体系如下图所示：
1.开发工具
此次主要采用的开发工具如下：
IDE:Spring Tool Suite；
SDK:JDK1.7及以上；
单元测试：Junit、Mockito；
集成测试：待定；
性能测试：JMeter、LoadRunner；
代码生成器：自主研发的CodeGenerator；
业务流程设计器：自主研发的Activit Designer；
2.技术规范
此次涉及的技术规范主要如下：
平台开发规范；
接口设计规范；
数据库设计规范；
统一返回码规范；
日志规范；
过程管理规范；
QA规范；
投产运维规范；
3.开发、运行环境
一、 WEB前端开发框架
WEB前端采用Tesla平台自主研发的TESLA-UI框架，该框架采用时下比较流行的MVVM设计模式，使用SeaJS进行JavaScript模块化管理，提供了基于JQuery的UI组件库和UI皮肤库，以及基于HTML的布局模板，适用于企业管理类型前台页面的开发。
二、 服务开发框架
后台服务采用行方自主研发的Tesla平台，该平台采用“微内核”+“组件”设计，稳定的内核保证系统的健壮性，丰富的组件保证系统的灵活性、扩展性。
TESLA定义了良好的扩展机制和统一的模块交互机制，能够定制化地为应用系统提供各种基础功能，例如：IoC容器、数据访问、MVC框架、缓存、工作流、服务编排、系统集成、服务治理等等。
TESLA融合了诸多互联网领域的技术，包括高并发的Web服务端技术（WebX、SpringExt）、服务化架构下的服务治理技术（Dubbo）、大数据量分库分表技术（ZDAL）、分布式缓存技术（Redis、Memcached）、高性能数据源连接池技术（Druid）、分布式配置管理技术（Disconf）等等。
另外，TESLA具有应对金融领域业务系统复杂性的能力，在业务快速集成与分布式事务数据一致性处理上做了很多支持。
TESLA框架分层如下：
1.渠道层：负责接收客户端发来的请求，不同的协议可以启用不同的渠道，比如有http、webservice、Socket等。
2.业务功能层：抽象业务功能处理的概念，Function代表一个业务功能，Filter是过滤器（可以设置在不同的作用域，比如Function级别，Function组级别，整个应用级别）、Action是Function中执行的每一个活动，Context是整个架构的数据载体，PamameterProcesser是参数处理器，用于参数进行校验和转换。
3.服务成层：Tesla采用“微内核”+“组件”设计，所有的服务组件都在这一层，都是开发中常用的一些基础功能，比如分页、缓存、工作流引擎、服务编排引擎、序列号生成器等。
4.集成层：负责和外部系统进行交互，RPC调用、Ftp、消息中间件等，同时纳入到服务治理体系。
5.开发工具集：全栈代码生成器，服务客户端代码生成器、业务流程设计器等。
6.数据访问层：负责DAO数据库SQL操作（基于Mybatis）、管理数据库连接池、事务、基于ZDAL进行分库分表。
7.基础设施：面向运维的一些支持设施，无需额外开发，如统一应用监控中心、配置管理中心、服务注册中心、异常处理平台集成等。
三、 中间件和技术平台
1.应用服务器
开发环境、单元测试环境：Tomcat7及以上；
集成测试环境、UAT测试环境、生产环境：Weblogic10；
2.WEB服务器
开发环境、单元测试环境：Tomcat7及以上；
集成测试环境、UAT测试环境、生产环境：Apache，Nginx；
3.分布式数据一致性管理
Zookeeper;
4.缓存
Redis
5.容器
Docker
6.JVM
开发环境、单元测试环境：Sun Hotspot 1.7及以上；
集成测试环境、UAT测试环境、生产环境：JRockit 7及以上；
四、系统软件平台
1. 数据库
总行：DB2 10及以上；
分行：根据分行具体情况任选其一：DB2、MySQL、Oracle；
2. 操作系统
DB2数据库服务器：IBM AIX；
其它服务器：SUSE Linux；
五、 系统硬件平台
1. 使用行方现有的虚拟化服务器；
4.过程管理
此次主要采用的过程管理工具如下：
项目构建：Maven；
版本控制：SVN；
构件仓库：Nexus；
缺陷跟踪：JIRA；
代码审查：FishEye、Crucible；
知识管理：Confluence；
持续集成、持续交付：Bamboo；
4.4.4.3.2 持续集成、持续交付
上述章节介绍了分行特色业务云平台的总体技术体系，在此，针对贯穿整个项目实施过程，保证项目质量、项目实施进度，减少项目实施风险的软件过程管理中的持续集成和持续交付的流程进行详细地说明，以便指导和约束整个软件实施过程。
正如本文《软件架构设计思想》章节中描述的，架构的本质就是通过“分“与”合“的手段，对系统进行有序化重构，不断减少系统无序的程度，使系统不断进化。
从一个简单的单体应用到分布式应用，再到更为复杂的微服务架构，除了关心如何拆、怎么拆的问题，还必须关注如何控制拆的风险、如何保证代码质量、如何保证功能符合用户需求等。
解决上述问题的手段就是集成，从一开始就集成，并且不断的集成，反复的将拆分的子系统、模块、组件重新组合，看看是否能够顺利组合起来，并且保证功能的不变。
实现上述不断地集成以及成果物交付的过程就是持续集成和持续交付：
1.持续集成：指对代码的提交，构建，测试的过程，这是一个持续、反复的过程。
2.持续交付：指将集成好的交付物，例如war、jar或者容器镜像，部署在联调环境，或者预发环境的过程。
以下是本项目采用的一个持续集成、持续交付的过程，研发团队在项目实施过程中要严格遵守：
持续集成、持续交付的基本流程如下：
1. 代码开发，完成分配的任务。
2. 每天提交代码，降低代码集成的风险。采用SVN的提交方式，后提交者有责任去merge，保证代码的编译通过和测试通过。
3. 专人定期审核提交的代码，把控代码质量。
4. 代码审核完毕之后，触发编译过程，完成代码编译。
5. 编译完成，进行单元测试。要求每个类都要有单元测试，并且单元测试覆盖率要达到一定的指标。单元测试要有带Mock的模块内的集成测试。如果单元测试不通过，则统计后发邮件，抄送所有的人。
6. 单元测试通过以后，上传成果物（war、jar或其它）至Nexus私服。
7. 如果采用私有云，并且使用docker容器，则需要编译Dockerfile，使用Docker镜像作为交付，能够实现更好的环境一致性，保证原子的升级和回滚。
8. 每天下班前，当天的代码需要提交到库中去，晚上会做一次统一的环境部署和集成测试。这个集成测试或者叫回归测试每天晚上都做，都是在一个全新的环境中。如果某一天测试不通过，则会发邮件通知。
9. 一个周期完毕，进行UAT测试。如果测试不通过，则会发邮件通知，开发人员要及时更正。
10.UAT测试通过以后，准备上线到生产环境。建议采用灰度发布或蓝绿发布机制，分批次发布、切换流量。一般情况下，具有权限的管理人员通过自动化脚本进行部署。
通过持续集成、持续交付这套完整的流程，层层保证质量，保证项目可以按时按质的完成，减少项目的实施风险
————————————————
版权声明：本文为CSDN博主「任性之闲来无事」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/beyondself_77/article/details/79844785
