浅析微服务的拆分

一、怎么拆分微服务？

拆分微服务的时候，为了尽量保证微服务的稳定，会有一些基本的准则：

1、微服务之间尽量不要有业务交叉。

2、微服务之间只能通过接口进行服务调用，而不能绕过接口直接访问对方的数据。

3、高内聚，低耦合。

怎样设计出高内聚、低耦合的微服务

高内聚低耦合，是一种从上而下指导微服务设计的方法。实现高内聚低耦合的工具主要有

同步的接口调用(Feign) 和异步的事件驱动(MQ，ApplicationEventPublisher\@EventListener) 两种方式。

 

二、DDD领域驱动设计

什么是DDD?

在2004年，由Eric Evans提出的，DDD是面对软件复杂之道，Domain-Driven-Design。

Martin Fowler -> 贫血模型 -> 贫血失忆症。

充血模型

MVC架构 -> 领域优先的四层架构

贫血模型：业务和数据是割裂的，实体里面完全体现不了业务。贫血失忆症。

充血模型：业务和数据是放在一起的，比如价格，addPrice(), setPrice()方法，这样的话，这个实体里面，有哪些业务就一目了然了。

以Entity为核心，把它们包装成一个一个领域，也就是说在应用层看到的是一个一个的领域，这个领域具备了领域内的所有行为。

所有与底层的操作，包括数据库，MQ这些操作，就是基础层。

业务之间会有很多的关联，代码都是混合在一起的，比如Product Entity，在物流领域我可能更关注它的长宽高，而在销售领域我可能更关注它的库存量，价格。

大泥团：

不利于微服务的拆分。大泥团结构拆分出来的微服务依然是泥团结构，当服务业务逐渐复杂，这个泥团又会膨胀成大泥团。

大泥团结构，虽然，拆成不同的微服务，但是在业务上，在领域上依然是重用的，物流啊价格啊，这些业务实际上还是重合的。

随着软件的不断复杂，不断复杂，最终都会落到同一个产品表，那它们的产品表，最终还会是原来的Product，业务行为实际上还是重叠的。

DDD只是一种方法论，没有一个稳定的技术框架。DDD要求领域是跟技术无关、跟存储无关、跟通信无关。

你这个领域不管是放在单体架构内，还是放到微服务架构内，它都是足够的高内聚，低耦合的。

三、什么是中台？中台和微服务有什么关系？

中台这个概念是由阿里在2015年提出"小前台，大中台"战略思想。

所谓中台，就是将各个业务线中可以复用的一些功能抽取出来，剥离个性，提取共性，形成一些可复用的组件。盒马鲜生、团购。

大体上，中台可以分为三类 业务中台、数据中台和技术中台。

大数据杀熟-数据中台

电商 收银中台 支付风控中台

中台跟DDD结合：DDD会通过限界上下文将系统拆分成一个一个的领域，而这种限界上下文，天生就成了中台之间的逻辑屏障。

DDD在技术与资源调度方面都能够给中台建设提供不错的指导。

DDD分为战略设计和战术设计。上层的战略设计能够很好的指导中台划分，下层的战术设计能够很好的指导微服务搭建。

在目前阶段，DDD还大都处在小范围实验的阶段。

四、你的项目中是怎么保证微服务敏捷开发的？微服务的链路追踪、持续集成、AB发布要怎么做？

开发运维一体化

敏捷开发：目的就是为了提高团队的交付效率，快速迭代，快速试错。

每个月固定发布新版本，以分支的形式保存到代码仓库中。快速入职、任务面板、站立会议。团队人员灵活流动，同时形成各个专家代表。

测试环境 -> 生产环境  开发测试环境SIT、集成测试环境、压测环境STR、预投产环境、生产环境PRD。

文档优先。晨会、周会、需求拆分会。

链路追踪

1.基于日志。形成全局事务ID，落地到日志文件。filebeat-logstash-Elasticsearch 形成大型报表。

2.基于MQ，往往需要架构支持。经过流式计算形成一些可视化的结果。

持续集成

SpringBoot maven pom -> build -> shell; Jenkins.

AB发布

1、蓝绿发布、红黑发布。老版本和新版本是同时存在的。

2、灰度发布、金丝雀发布。

视频教程