1、微服务的拆分原则问题？

【问题描述】按一般原则来讲，微服务的拆分是应该从横向角度进行拆分。但是在一些业务流程中，如果想从纵向角度进行拆分，如何能够更好的实现合理拆分，并且不影响系统的响应时间等性能指标？

@尘世随缘 上海某互联网金融公司  技术总监：

如何拆分微服务，这个目前没有一个原则或者标准可以参考，但是大致可以看到：

1、单一职责、高内聚低耦合：简单来说一张表划分为一个服务

2、服务粒度适中：服务不要太细（有的团队甚至一个接口一个服务）

3、 以业务模型切入：比如产品，用户，订单为一个模型来切入

4.、演进式拆分：刚开始不要划分太细，可以随着迭代过程来逐步优化

5.、避免环形依赖与双向依赖：尽量不要做服务之间的循环依赖

@gavin_zhang 某股份制银行 系统架构师：

一楼的回答应该已经很全面了，我来补充几点实践的：

1、服务分层，将系统的功能进行分层，服务归属于前后中台，层间单向调用，有效控制调用深度

2、数据耦合，对于需要跨机事务的拆分，要重点分析，是否可以通过服务功能的调整避免（如将两段式提交变成数据副本的最终一致性），如果确实不行，对拆分的必要性进行确认。

@狄俄尼索斯 UProject 软件架构设计师：

接着2楼的再补充一点：按照功能重要程度拆分。

2、微服务拆分如何平衡拆分粒度？

【问题描述】目前很多传统的单体应用再向微服务架构进行升级改造，如果拆分粒度太细会增加运维复杂度，粒度过大又起不到效果，改造过程中如何平衡拆分粒度？

@尘世随缘 上海某互联网金融公司 技术总监：

1、高内聚低耦合，服务粒度适中

2、以业务模型切入

3、演进式拆分

4、阶段性合并

总的原则: 拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过 2 个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。

@我爱大锅饭 银行 系统运维工程师：

关于这个问题，引用 Spring Cloud Alibaba成员姬望（彭文杰）的一篇采访内容，核心的观点及段落内容如下：

微服务解决的本质问题是团队分工：

SOA 也好、微服务也好，解决的根本问题是团队分工问题，详见康威定律，这是大型软件发展的必然，不因为人的喜好而改变。当你读懂康威定律，就会发现“服务拆分粒度难以准确把握”根本不是本质问题。你有几个 2 pizza 团队，最好就拆成几个微服务。举一个现实的例子：只有一个开发人员时，尽量就做单体应用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，包含开发、测试、运维），当然我们也实施过一些传统大型企业，但团队还是处在横向结构的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很痛苦，尤其是运维团队。

这里面的概念可以网上查下，我个人觉得说的还是非常有道理的。我辖内的系统就经历了单体应用向微服务拆分的过程，拆分的背景是行内一个秒杀内的业务需要调用辖内系统应用，传统的架构性能不满足要求，故进行容器化改造，对此业务场景涉及的业务进行微服务拆分。乍看下来是业务驱动，但实际上这个系统的开发团队也因此做了拆分，安排专人服务微服务模块的开发、测试，运维方面暂未拆分。但是如果拆分的范围进一步扩大，运维团队拆分也是必然。

3、服务之间的数据一致性对服务拆分有什么影响？

@Steven99 软件架构设计师：

数据一致性通常基于业务相关，需要考虑强一致性，弱一致性。弱一致性通常可以拆分为不同的服务，强一致性可以定义为一个微服务，但也要看业务的复杂性等因素

@gavin_zhang 某股份制银行 系统架构师：

数据一致性是服务拆分的时候的一个重要依据，对于强一致的数据，属于强耦合，理论上应该是放在一个服务中，但是有时会因为各种原因需要进行拆分，那就需要有响应的机制进行保证。另外，微服务设计时，可以尽量使用命令模式之类的设计模式，尽量减少需要强一致的数据范围。可以为后续的开发节省很多精力。

4、单体应用该如何按领域模型进行微服务化拆分？

@尘世随缘 上海某互联网金融公司 技术总监：

很多团队面临这样的问题，服务到底如何拆分，怎么样的拆分是合理的，拆分后新的微服务框架和老的系统如何做兼容运行，老系统如何逐步平滑过渡到微服务架构中，而且不影响线上业务运行，也不能影响正常的项目迭代。其实，业界没有标准的方式来指导如何做拆分，我们主要围绕“拆“ 与 ”合“来做服务的拆分，所谓拆就是按业务功能拆分，所谓”合“，就是拆分后的模块经过多次迭代后可以做合并处理。比如按用户维度，按订单维度，按产品维度等，比如订单维度拆分后订单服务变更还是非常多，改动非常大，那么订单继续拆分。

5、拆分微服务有没有方法论？

@Steven99 软件架构设计师：

我们觉得微服务定义和拆分都要基于业务来考虑，因为微服务最终是为了实现业务需求，所以不同的业务需求，微服务定义和拆分可能会不一样，可以看主数据管理，DDD 的书籍，具体的微服务拆分最好能通过咨询项目来做，可以少走弯路。

@gavin_zhang 某股份制银行 系统架构师：

拆分的方法论还是有的，比如 DDD ， EventStorming 等。方法是死的，人是活的，再好的方法也需要人来执行，这块对整个业务流程要求非常的熟悉，最好是架构师和业务人员一起做这块的划分。

对于不是太复杂的系统，可以参考以下方法：

可以将系统的业务对象（这里的业务对象是业务人员的视角，不是开发人员的）进行归纳，记录每个业务对象之间的交互，对每个交互进行标注，那些是强一致的，那些是最终一致的。切分是，尽量找交互少的，支持最终一致性的关联进行切分。得到一个比较顶层的服务划分，再根据服务对象之间的数据共享进行梳理，提取公用的数据服务。

6、微服务拆分有哪些误区？

@gavin_zhang 某股份制银行 系统架构师：

第一个最常见的误区是划分服务的时候，按照业务流程的步骤进行划分，这是开发人员传统的面向过程的思维定势造成的。也可能是传统的SOA过度而来的一种划分方式。这种划分微服务的最大缺点在于，服务与服务之间存在很强耦合性，服务的优雅降级无从做起，而且还存在大量的跨机事务需要解决。

另外一个问题就是基础功能或是公共代码的问题，开始采用微服务架构时，很多项目喜欢将基础功能独立成为一个服务，这些基础功能不是业务功能，而是一部分公用的非独立的功能。在项目的初期，这种设计确实是提高了代码的复用，但是随着系统需求的变化，这些基础服务会被频繁修改，导致变得复杂难以维护。这种为了实现代码共享的基础服务，破坏了服务自治的约束，提高了部署和运维的难度，降低了系统的可用性。