微服务拆分探讨
作者：互联网
一、如何拆分微服务，这个目前没有一个原则或者标准可以参考，但是大致可以看到：
1、单一职责、高内聚低耦合
2、服务粒度适中：服务不要太细
3、 以业务模型切入：比如产品，用户，订单为一个模型来切入
4.、演进式拆分：刚开始不要划分太细，可以随着迭代过程来逐步优化
5.、避免环形依赖与双向依赖：尽量不要做服务之间的循环依赖
6、数据耦合，对于需要跨机事务的拆分，要重点分析，是否可以通过服务功能的调整避免（如将两段式提交变成数据副本的最终一致性），如果确实不行，对拆分的必要性进行确认
（ps：以下针对拆分原则问题，网上找的一些符合个人想法类似的描述）
二、微服务拆分粒度
目前很多传统的单体应用再向微服务架构进行升级改造，如果拆分粒度太细会增加运维复杂度，粒度过大又起不到效果，总结几个基本原则
1、高内聚低耦合，服务粒度适中
2、以业务模型切入
3、演进式拆分
4、阶段性合并
SOA 也好、微服务也好，解决的根本问题是团队分工问题，详见康威定律，这是大型软件发展的必然，不因为人的喜好而改变。当你读懂康威定律，就会发现“服务拆分粒度难以准确把握”根本不是本质问题。你有几个 2 pizza 团队，最好就拆成几个微服务。举一个现实的例子：只有一个开发人员时，尽量就做单体应用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，包含开发、测试、运维），当然我们也实施过一些传统大型企业，但团队还是处在横向结构的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很痛苦，尤其是运维团队。
三、服务之间的数据一致性对服务拆分的影响（主要是依赖数据库事务，保证数据一致性依据）
1.数据一致性是服务拆分的时候的一个重要依据，对于强一致的数据，属于强耦合，理论上应该是放在一个服务中，但是有时会因为各种原因需要进行拆分，那就需要有响应的机制进行保证。另外，微服务设计时，尽量减少需要强一致的数据范围。可以为后续的开发节省很多精力。
2.对于不是太复杂的系统，可以将系统的业务对象进行归纳，记录每个业务对象之间的交互，对每个交互进行标注，那些是强一致的，那些是最终一致的。切分是，尽量找交互少的，支持最终一致性的关联进行切分。得到一个比较顶层的服务划分，再根据服务对象之间的数据共享进行梳理，提取公用的数据服务。
总结：
最终拆分后一般情况 ：
1.服务调用路径层级不可过深
2.合理的拆分数据库表结构，对于强一致的数据，属于强耦合，理论上应该是放在一个服务中（不然会存在大量的跨库跨机事务需要解决）
3.如果是已有系统进行微服务化，先把大系统拆成多个中系统，然后再继续拆成小系统
4.根据业务模式而定
四个重要的设计原则
一、垂直划分优先。
企业应该根据业务领域对服务进行垂直划分，因为水平划分有可能导致下面这些问题，比如调用次数更多，导致性能大幅下降；实现一个功能要跨越更多服务，沟通成本增加等。
二、持续演进。
服务数量快速增长带来架构复杂度急剧升高，开发、测试、运维等环节很难快速适应，会导致故障率大幅增加，可用性降低。非必要情况，应逐步划分、持续演进、避免服务数量的爆炸式增长。这等同于灰度发布的效果，先拿出几个不太重要的功能拆分出一个服务做试验，即便出现故障，影响范围也不会太大。
三、服务自治、接口隔离。
尽量消除对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性。服务通过标准的接口隔离，隐藏内部实现细节。这样可以让服务保持独立开发、测试、部署、运行，以服务为单位持续交付。
四、自动化驱动。
部署和运维的成本会随着服务的增多呈指数级增长，每个服务都需要部署、监控、日志分析等运维工作，成本会显著提升。因此，在服务划分之前，应该首先构建自动化的工具及环境。开发人员应该以自动化为驱动力，简化服务在创建、开发、测试、部署、运维上的重复性工作，通过工具实现更可靠的操作，避免微服务数量增多带来的开发、管理复杂度问题。
标签：拆成,服务,运维,探讨,粒度,拆分,团队 来源： https://www.cnblogs.com/jessica888/p/14995351.html