微服务架构思考

近些年来非常火爆的微服务架构，曾经让我以前团队（某团团购后台组）从泥沼中脱身出来，轻松的应对线上大量的业务压力，而如今却让我现在的团队深入泥沼中。

甜蜜的经历

12年刚来某团团购后台组的时候，只有一个项目groupapi。只有4个RD因对C端版本迭代的开发，从3.5版本每日访问量1KW。后来随着业务队伍的扩大，一个项目逐渐拆成10个项目（推荐，push，广告...）。再后来随着日访问量的增加，团购内部开始拆分成不同的微小服务（groupdeal，sinai（poi查询），sieve（deal，poi检索），groupgeo...）。但是很明显的一个感受就是casestudy比上个季度少了很多。通过微服务，每个小团队都只需要全心关注自己的一个比较纯粹，比较单一的服务。这样单个服务的可用性能可以提高到好几个个9。通过分层的架构能保证每次业务迭代，上线流程都非常清晰简单。通常情况一般上线都只牵涉到一到两个服务。上线步骤也比较简单，同时能平滑发布，回滚。

下面稍微总结下微服务架构带来的好处：

1. 每个小组专注于一个微型服务，致力于该服务的稳定性，可用性，服务性能，以及业务的迭代开发
2. 通过分层的架构模式，让发布流程简单，平滑发布回滚
3. 整体上事故次数减少，每次事故影响范围减少
4. 因为团购后台有统一的API接入层，并且有稳定的团队在负责，所以与C端同学的对接比较顺畅。与C端对接包含高质量的接口文档，设计良好的URL，低bug的接口开发，规定时间内开发，联调完毕。因为有统一的API接入层，所以与C端同学打交道很舒畅，大家都很幸福

痛苦的经历

换到一个新的项目组后，真心体会到很多重要原则没有把握好会把微服务架构玩坏。先把情况简单介绍下：

新团队不是采用演进的方式进行微服务，而是按照职能切分成几大块。几大块之间并没有分层设计，还是网状堆砌起来（很明显的一个问题就是相互依赖）。同时个大块之间并没有实现不该关心逻辑的透明化。简单讲就是一个服务其实对外应该是黑盒。内部的结构，内部独有的逻辑应该对外部服务透明，不应该还对外暴漏。但是现实的情况是服务对外并没有实现很好的封装。

举例说明：supplier项目相当于与第三方供应商对接的网关。supplier需要维护与每个第三方供应商的权限，认证，服务code，手艺人code。但是出乎意料的是supplier居然把鱼第三方交互的code，流露到了别的服务系统。本应该是其独有与第三方交互的逻辑，信息却需要别的服务关心，没有做到透明的封装。

微服务划分

服务究竟应该如何的划分才更加合理？这个问题我想了很多，其实难以给出一个标准的答案。但是从实践来看，确实有一些线索可以追寻的。回到上面的groupapi的演进来看，有一个准则：唯一权责原则。如果你的服务中涉及到做了多个事情，意思是没有做到唯一权责原则，那么就可以将其中的一部分抽取出去，单独维护。其实这里强调了一个演进的过程。我觉得微服务化更多是一个演进的步骤，而非自上向下的生硬划分。

微服务划分粒度的大小：

微型服务划分大小确实会给工程带来不同的bug密度，下面一张图来自《UNIX编程艺术》，将的是模块划分的粒度与bug密度的关系。从宏观角度来看，微型服务与模块有本质上的相同。下面图形中，看到bug密度                      

                                 

微服务架构切记：

1. 一个单独的微型服务，尽量保证纯粹，良好的封装性。良好的封装表示不会对外暴露自身的细节。
2. 微型服务的组织尽量保证有一定的层次性，不要胡乱的或者网状的组织微型服务，不要出现胡乱依赖，循环依赖。
3. 微型服务切记不要划分的太细，也不要划分的太粗。具体那个度适中，这个需要根据具体的case进行思考
4. 每个微型服务都应该时刻惊醒===>自己依赖的服务。每个这些外部服务的健康状况都会对你的服务产生直接影响。同时你要经常梳理自己的服务的依赖，如果不是真正的必要，不要引入别的服务的依赖