服务化拆分的两种姿势

那么服务化拆分具体该如何实施呢？
一个最有效的手段就是将不同的功能模块服务化，独立部署和运维。以前面提到的社交 App 为例，
你可以认为首页信息流是一个服务，评论是一个服务，消息通知是一个服务，个人主页也是一个服务。
这种服务化拆分方式是纵向拆分，是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，
而功能相对比较独立的业务适合单独拆分为一个微服务。

还有一种服务化拆分方式是横向拆分，是从公共且独立功能维度拆分。
标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。继续以前面提到的社交 App 举例，
无论是首页信息流、评论、消息箱还是个人主页，都需要显示用户的昵称。假如用户的昵称功能有产品需求的变更，你需要上线几乎所有的服务，
这个成本就有点高了。显而易见，如果我把用户的昵称功能单独部署成一个独立的服务，那么有什么变更我只需要上线这个服务即可，
其他服务不受影响，开发和上线成本就大大降低了。

横向拆分:把一些不会和其他主业务有依赖的功能拆分出来，最典型的就是common。
纵向拆分:按照业务来拆分，比如用户访问一个商城，从访问到下单成功会调用很多服务，我们可以把用户登录做一个服务，商城首页以及商品信息做一个服务，购物车模块是一个服务，支付模块又是另一个服务，这样整个商城都是微服务架构，不管哪个单独的服务出现问题，都不会影响别的服务，方便于技术人员最快定位问题，解决问题。
准确来说，一个项目里边是横向和纵向都有的，并不冲突，微服务带给我们的好处有很多，但具体能不能使用微服务还要根据具体的项目和团队来决定。
(以上拆分仅供举例参考，具体拆分视项目而定)