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

当不断从单体架构中抽象服务的时候，哪些服务优先被拆分，哪些服务不需要被拆分?以下几个策略可以帮助解决拆分中的这些问题。

• 比较独立的新业务优先采用微服务架构。从成本角度考虑，新业务采用新的架构是最合理的，因为这样做对老业务的影响最小。
• 优先抽象通用服务。因为通常通用服务的边界比较明显，耦合度低，比较容易分离。
• 优先抽象比较容易识别的、边界比较明显的服务。如果原有包结构比较清晰，可以基于原有包结构中有明显边界的、比较完整的业务进行划分，这是从成本角度考虑。如果已经基于单体架构开发了一段时间，对业务的理解程度已经非常高，那么开发及架构人员能够比较容易地提炼出一些边界比较明显的服务。
• 优先抽象核心服务。因为微服务的开发及运维成本比较高，并不是所有的地方都需要划分很小的粒度。往往一些比较边缘的运营、管理的系统甚至不会考虑拆分。另外，随着时间的推移，有一些业务可能会发生改变，因此应该先抽象出核心服务。
• 优先抽象具有独立属性的服务。应根据功能的变更频率、资源占用、技术栈等属性划分服务。
• 采用绞杀者模式，在遗留系统外围，随着时间的推移，让新的服务逐渐“绞杀”老的系统。在这种情况下，复杂度往往体现在如何灰度发布、迁移数据，以及如何保障服务不中断，后面的章节会详细描述。

如何衡量服务划分的合理性

每个产品在实施微服务架构最初的动力都不一样，目标也有所区别，所以判断是否划分合理，首先要看是否达成了目标。其次，可以参考以下几种衡量方式。每种衡量方式不能单独作为一个判断标准，需要综合考虑。

• 一个小功能的修改从需求到上线需要多长时间?正常情况下的微服务架构交付周期应该是以天为单位的。如果一个小功能的修改需要几周到几个月的时间，可能意味着服务划分粒度过大，存在太多的冲突，要等待合并代码。
• 大多数功能修改是否可以在一个服务内完成?如果经常需要跨服务团队的联合开发组才能完成一个新功能的开发或者旧功能的修改，则说明服务划分存在问题。
• 是否要频繁修改接口?频繁修改接口有可能是接口设计不合理导致的，也有可能是服务划分的问题导致的，说明服务之间的边界并不是特别明确和稳定。
• 响应时间是否能满足要求?在某些追求极致性能的场景中，对响应时间要求较高，服务划分的层次太多、粒度太小都可能导致响应时间不能满足要求。
• 是否存在大量的跨服务更新?是否存在大量的跨服务的关联查询?出现这两个问题，可能是因为划分不合理。

微服务划分反模式

前面我们介绍了如何划分服务，在此之上，我们希望通过微服务划分的反模式来帮助大家少走弯路。

根据代码行数划分服务

代码规模太大会导致沟通效率、交付效率低下，耦合度高，以及比较笨重。代码规模可以作为一个参考，但是不能作为一个绝对标准，微服务架构中存在一个“大服务”是很正常的。基于代码行数拆分服务很难衡量服务的完整性，容易导向更小的拆分粒度，引起不必要的复杂度。

划分粒度越小越好

（编辑：西安站长网）

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