来吧,说说你眼中的微服务(2)
当不断从单体架构中抽象服务的时候,哪些服务优先被拆分,哪些服务不需要被拆分?以下几个策略可以帮助解决拆分中的这些问题。
如何衡量服务划分的合理性 每个产品在实施微服务架构最初的动力都不一样,目标也有所区别,所以判断是否划分合理,首先要看是否达成了目标。其次,可以参考以下几种衡量方式。每种衡量方式不能单独作为一个判断标准,需要综合考虑。
微服务划分反模式 前面我们介绍了如何划分服务,在此之上,我们希望通过微服务划分的反模式来帮助大家少走弯路。 根据代码行数划分服务 代码规模太大会导致沟通效率、交付效率低下,耦合度高,以及比较笨重。代码规模可以作为一个参考,但是不能作为一个绝对标准,微服务架构中存在一个“大服务”是很正常的。基于代码行数拆分服务很难衡量服务的完整性,容易导向更小的拆分粒度,引起不必要的复杂度。 划分粒度越小越好 服务的大小并不是特别重要,可以根据团队规模、代码规模、业务复杂度、技术领域、重要程度、成本等因素综合考虑。关于服务粒度的大小,业界并没有统一标准,也很难衡量,最接近的衡量标准是研发团队规模。粒度小意味着更高的维护成本。后端管理、辅助系统通常粒度较大。 一次性划分服务 拆分服务有如下两种方式。 第一种,先拆分业务代码再拆分数据库。如图2-9所示,数据库并没有拆分,只是从单体中抽象出部分服务。 图2-9 先拆分业务代码再拆分数据库 第二种,业务代码和数据库同步拆分。如图2-10所示,部分业务服务被拆分出来的同时,数据库也被同步拆分出来。 图2-10 业务代码和数据库同步拆分 采用第二种方式拆分服务时,根据服务将数据库彻底拆分为多个独立的数据库,每个服务独享数据库服务,服务之间只能通过接口调用。这看起来非常美好,但需要为此做大量的数据迁移。当业务处于初期,需求不是非常确定,开发人员对业务理解不是特别透彻的时候,可能拆分后发现拆分得并不合理,只能再进行合并,又要进行一次数据迁移。相对来说,业务代码拆分成本更低,而数据迁移的成本更高,频繁、大量的数据迁移并不可取。 更好的做法是把第一种方式作为过渡阶段,当业务逐步稳定后再彻底进行数据迁移。注意,处于过渡阶段时数据库并没有彻底分离,一切依赖都通过接口访问。但是这只是口头上的约定,对于业务开发人员直接在数据库中进行关联查询。需要通过Code Review的方式避免。 服务划分是一个长期的过程,需要积累大量的领域知识,以此来理解核心流程。最好是和领域专家一起组成联合团队,在理解核心问题的情况下,持续拆分服务并验证拆分合理性,随着时间的推移,还可以重新划分。可见,服务拆分是一个持续性的过程。 服务划分一旦完成,不能改变 由于业务的不断变化,以及开发人员对领域知识和其他影响因素的理解等问题,很难一次性做出一个完美的解决方案。通常在划分后会发现,某个问题是不可忍受的,例如划分后导致响应时间降低,增加了更多的成本,有可能需要重新合并服务;由于业务的变化,原本的依赖关系发生了变化,有可能面临需要重新划分服务等类似的问题。 先实施组件化,再实施微服务架构 很多技术人员试图先通过组件化逐步过渡到微服务架构,这是一种错误的思路。微服务架构划分更强调业务领域的完整性,因此垂直划分优先,而组件化往往通过抽象出稳定的部分形成组件共享,对调用次数和依赖关系并不强调。因此,组件化之后再转化到微服务架构的方式,通常是错误的。
(编辑:ASP站长网) |