硬核实战分享：企业微服务架构设计及落地的六大难点介绍

以用户管理举例，在初始阶段的做服务拆分的时候，把用户管理拆分为用户服务，且具备了用户的增删改查功能，在互联网中流量获客是最贵的，运营团队通过互联网投放广告获客，用户在广告页上填写手机号码执行注册过程，如果此时注册失败或者注册过程响应时间过长，那么这个客户就可能流失了，但是广告的点击费用产生了，无形中形成了资源的浪费。当用户规模上升之后需要对增删改查功能做优先级划分，所以此时需要按方法维度来拆分服务，把用户服务拆分为用户注册服务(只有注册功能)，用户基础服务(修改、查询用户信息)。

 哪些功能需要被拆分成服务

无论是单体应用重构为微服务架构，还是在微服务架构体系下有新增需求，都会面临这些功能或者新增需求是否需要被拆分为服务。虽然没有相关规定，但是可以遵循服务拆分的方法论：当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过 2 个或以上的其他服务或客户端提供数据，应该被拆分成一个独立的服务模，而且拆分的服务要具备高内聚低耦合。所谓的高内聚是指一个组件中各个元素互相依赖的程度，是衡量某个模块或者类中各个代码片段之间关联强度的标准，比如用户服务，只会提供用户相关的增删改查信息，假如还关联了用户订单相关的信息，那就说明这个功能不是高内聚的功能，拆分的不好。

低耦合是指系统中每个组件很少知道或者不知道其他独立组件的定义，其中的组件可以被其他提供相同功能的组件替代。

（编辑：云计算网_泰州站长网）

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