来吧，说说你眼中的微服务

服务的大小并不是特别重要，可以根据团队规模、代码规模、业务复杂度、技术领域、重要程度、成本等因素综合考虑。关于服务粒度的大小，业界并没有统一标准，也很难衡量，最接近的衡量标准是研发团队规模。粒度小意味着更高的维护成本。后端管理、辅助系统通常粒度较大。

一次性划分服务

拆分服务有如下两种方式。

第一种，先拆分业务代码再拆分数据库。如图2-9所示，数据库并没有拆分，只是从单体中抽象出部分服务。

图2-9 先拆分业务代码再拆分数据库

第二种，业务代码和数据库同步拆分。如图2-10所示，部分业务服务被拆分出来的同时，数据库也被同步拆分出来。

图2-10 业务代码和数据库同步拆分

采用第二种方式拆分服务时，根据服务将数据库彻底拆分为多个独立的数据库，每个服务独享数据库服务，服务之间只能通过接口调用。这看起来非常美好，但需要为此做大量的数据迁移。当业务处于初期，需求不是非常确定，开发人员对业务理解不是特别透彻的时候，可能拆分后发现拆分得并不合理，只能再进行合并，又要进行一次数据迁移。相对来说，业务代码拆分成本更低，而数据迁移的成本更高，频繁、大量的数据迁移并不可取。

更好的做法是把第一种方式作为过渡阶段，当业务逐步稳定后再彻底进行数据迁移。注意，处于过渡阶段时数据库并没有彻底分离，一切依赖都通过接口访问。但是这只是口头上的约定，对于业务开发人员直接在数据库中进行关联查询。需要通过Code Review的方式避免。

服务划分是一个长期的过程，需要积累大量的领域知识，以此来理解核心流程。最好是和领域专家一起组成联合团队，在理解核心问题的情况下，持续拆分服务并验证拆分合理性，随着时间的推移，还可以重新划分。可见，服务拆分是一个持续性的过程。

服务划分一旦完成，不能改变

由于业务的不断变化，以及开发人员对领域知识和其他影响因素的理解等问题，很难一次性做出一个完美的解决方案。通常在划分后会发现，某个问题是不可忍受的，例如划分后导致响应时间降低，增加了更多的成本，有可能需要重新合并服务;由于业务的变化，原本的依赖关系发生了变化，有可能面临需要重新划分服务等类似的问题。

先实施组件化，再实施微服务架构

很多技术人员试图先通过组件化逐步过渡到微服务架构，这是一种错误的思路。微服务架构划分更强调业务领域的完整性，因此垂直划分优先，而组件化往往通过抽象出稳定的部分形成组件共享，对调用次数和依赖关系并不强调。因此，组件化之后再转化到微服务架构的方式，通常是错误的。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!