应用拆分、解耦与灰度发布的探索与实践

一、应用拆分、解耦

随着架构风格的发展演进（尤其是微服务架构的出现和流行）和技术的迭代更新，对应用进行合理化的拆分在业界已有基本共识，但是拆分的维度和粒度，需要每个系统根据自身所属的业务条线、功能以及场景特点等综合情况去适配性考量。

系统内部拆分通用实施建议:

1、首先需要对系统的应用架构和数据架构进行梳理，定义好系统的职责和边界，模块划分及模块间关系，可以按下面表格内容对系统服务进行定义和分析。对现有技术栈要摸底，老旧接口代码丢失或不可维护的需要重规划设计。对于架构陈旧系统需进行系统升级，如传统后台和前台代码耦合的需要前后端分离，中间件升级包括spring、jdk、maven等工具需升级。

2、为了支持系统的横向扩展，将应用服务状态外置，系资统文件、缓存、Session、定时任务等源需要去状态，集中管理，支持共享。对于已经集群部署的系统，在部署时已经实现了服务状态外置。系统文件采用共享存储、缓存和session使用分布式缓存，定时任务通过统一协调调度。

3、数据模型上，分布式架构下，原有数据模型会分库分表，需要对数据模型重构，将服务内部数据聚合，避免跨模块的表关联。对于服务间的字段依赖，可以在模型设计上适当的设置冗余字段（实时性高，占空间），或采用组合交易加缓存的机制实现（业务逻辑复杂）。

4、应用的拆分包括应用和数据库。应尽量遵循同一个服务不要跨库进行写操作，如果涉及到多个服务写操作，需要进行分布式事务管理，保证不同数据库数据的一致性。

5、应用的自动化测试和自动化部署。微服务架构的核心是业务需求快速响应，是实现这个目标，需实现应用研发的敏捷转型。自动化测试和自动化部署，是微服务架构敏捷实践的基础，贯穿开发、测试、部署、运维全流程。通过接入容器云，实现应用自动化部署。引入自动化测试工具，将应用接口录入自动化测试工具，通过维护测试案例，将自动测试加入持续集成步骤。

二、灰度发布

实现思路方向：

1、在代码中控制。

一套线上环境，代码中做开关，对于不同的用户走不同的逻辑

优点：灵活，粒度细；一套代码(环境)运维成本低
缺点：灰度逻辑侵入代码

2、在接入层控制。

多套(隔离的)线上环境，接入层针对不同用户转发到不同的环境中
优点：无需（少）侵入代码；风险小
缺点：多套线上环境，运维成本高

灰度发布方面的实施建议:

1.使用nginx配置变更及其热加载的流量无损特性。发布前，更新nginx配置，请求跳过部分服务节点；更新这些服务节点的程序后，更新nginx配置，将部分流量分发至已更新的服务节点，并进行局部测试；进而完成全局更新。

2.使用eureka的服务注册与下线功能。下线部分服务节点后，更新这些服务节点的程序后，重新向服务中心注册，并进行局部测试；进而完成全局更新。

3.引入灰度发布框架或产品，或自研（成本较高），实现可定制化策略的(部分时间段可使用部分服务，部分ip段可使用部分服务等)全自动灰度发布。