拆分微服务的时候，为了尽量保证微服务的稳定，会有一些基本的准则：
1、微服务之间尽量不要有业务交叉。
2、微服务之间只能通过接口进行服务调用，而不能绕过接口直接访问对方的数据。
3、高内聚，低耦合。
怎样设计出高内聚、低耦合的微服务
高内聚低耦合，是一种从上而下指导微服务设计的方法。实现高内聚低耦合的工具主要有
同步的接口调用(Feign) 和异步的事件驱动(MQ，ApplicationEventPublisher\@EventListener) 两种方式。
什么是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、灰度发布、金丝雀发布。
视频教程
