微服务的服务拆分

微服务的陷阱

微服务一度让人痴迷，无序无规则的实施，最终带了很多问题：

• 服务划分过细，服务间关系复杂
  服务划分过细，单个服务的复杂度下降，但整个系统的复杂度却上升，微服务将服务内的复杂度转为了系统间的复杂度
• 服务数量变多，团队效率下降
  有没有遇到过一个人维护着好几个微服务的情况？有没有遇到一个团队几个人却拆分出了几十个微服务的？
• 调用链长，性能下降
• 调用链长，问题定位越来越难
• 部分公司并没有自动化支撑，并无法达成快速交付的预期
  –自动化部署缺少
  –自动化监控缺少
• 没有服务治理，微服务管理混乱
  –服务路由
  –服务故障隔离
  –服务注册与发现

微服务最佳实践

服务粒度

针对服务拆分过度导致的问题，最好按照团队规则进行拆分，最好3个人负责开发一个微服务，随着团队规模的扩大，可以将原有微服务再进行重新划分。3个人一个微服务，即保障了系统的复杂度可以很好的让每个人都能全面理解，又能让每个开发人员体现自己技术实力，人太多可能某些开发人员技术挑战的机会就没了；太少可能复杂度又不够。同时从团队管理来说，3个人可以很稳定的备份，即使1个人休假或者离职，其他2个也足够支撑。再次3个人对技术方案的确定才有可能形成有效讨论。

拆分方法

（1）基于业务逻辑拆分

最常见的拆分方式，将系统中的业务模块按照职责范围，每个单独的业务模块拆分为一个独立的服务。拆分时最好根据3个负责一个微服务原则，不要拆分过细。
如：如果团队只有10个人，划分4个服务，可能“订单、支付、购物车”都可以划到“订单服务”职责范围内了；要是有100个人，那“订单”就可以划分为一个单独的服务了。

（2）基于可扩展性拆分

将系统中业务模块按照稳定性进行排序，将已经成熟改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。稳定的服务可以粒度粗点，可能逻辑上关联不大也可以放至一个服务里，如：流程引擎，工单服务、分单服务基本不会变化，可在一个系统中。而不稳定的如：请假流程、离职流程等等可以放在不同的服务，但一定要管制数量。
这样拆分主要为了提升项目快速迭代，避免在开发时，对已有成熟功能有影响导致线上问题发生的机率。

（3）基于可靠性拆分

将系统中业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性低的非核心业务拆分出来，重点保障核心服务的高可用。
这样拆分为主要为了：避免非核心服务故障影响核心服务；核心服务高可用方案可以更简单；降低高可用成本。

（4）基于性能拆分

将性能要求高的或者性能压力大的模块拆出来，避免性能压力大的服务影响其他服务。比较典型的就是电商的秒杀服务。
以上拆分方法可以自由组合，但最好要根据3人负责一个微服务原则，有问人不够怎么办？加人呗。

微服务的基础设施

很多人有一种错觉微服务是一种“轻量级”、"简单"服务。但当微服务大量增加时，基础服务就显的越来越重要。微服务只是把复杂度转到了基础设施。
微服务的基础设施主要有以下服务：
1.服务发现
2.服务路由
3.服务容错
4.服务监控
5.服务跟踪
6.服务安全
7.自动化测试
8.自动化部署
9.配置中心
10.接口框架
11.API网关

服务发现

微服务种类和数量很多，服务的新增或者服务节点的扩容导致节点增加，也可能某一节点故障需要隔离一部分节点等都需要有服务自动发现能力，如果人工添加这几乎是不可能的任务。

服务路由

服务路由基本上不会独立部署，一般都会与服务发现共同提供服务，路由核心功能就是路由算法。常见的路由算法：随机路由、轮询路由、最小压力路由、最小连接数路由等算法。

服务容错

系统拆分为微服务后，单个微服务故障机率变小，故障影响范围也减少，但微服务的节点数量大大增加。从整体上来看，系统中某一个微服务节点出故障的概率会大大增加。此时如果系统不能自动应对出错场景，人工处理的话投入是巨大的。而且处理不及时还可能造成故障的扩散。
常见的容错包括：
1、请求重试
2、流量管控
3、服务隔离
微服务统常是集群部署，某一节点故障，最快最简单的处理方式是将故障节点下线隔离，避免故障进行扩散。服务隔离就分：主动隔离（微服务自己判断自己异常后，主动从服务发现系统中注销）、被动隔离（服务发现系统根据设定的规则判断微服务节点故障，将其注销）和手动隔离（人工判断）。

服务监控

系统拆分为微服务后，节点数量大大增加，导致需要监控的机器、网络、进程、接口调用情况等数据的数量大大增加；一旦发生故障快速定位故障成为一个困难的事。服务监控主要做以下几件事：
– 实时搜集信息并进行分析，避免故障后分析，减少处理时间。
– 服务监控可以在实时分析的基础上进行预警，如：接口TPS指标是否下降，在问题萌芽阶段发觉并预警。
通常情况，服务监控需要收集海量数据进行分析，一般是单独部署系统。

服务跟踪

服务监控可以做到微服务节点级的监控和信息收集，但如果我们需要跟踪某一个请求在微服务中的完整路径，服务监控是难以实现的。如果每个服务的完整请求信息都实时发送给服务监控系统，数据量会大到无法处理。
服务监控和服务跟踪的区别可以理解为统计与具体。如：A服务请求B服务10次，B返回JSON对象。服务监控会记录请求次数、响应时间平均值、响应时间最高值、最低值、错误码分布等；而服务跟踪会记录每次请求的发起时间、响应时间、响应错误码、请求参数、返回的JSON等信息。
目前请求跟踪的实现技术都基于Google的Depper论文，感兴趣可以自行百度。主要关键技术有以下：
– 标注点
– 跟踪树和span
– 采样跟踪
– 染色跟踪

服务安全

– 接入安全
– 数据安全
– 传输安全

自动化测试

自动化测试最好能涵盖代码级的单元测试、单个系统的集成测试、系统间的接口测试。至少要做到接口测试自动化。

自动化部署

自动化部署包括：版本管理、资源管理、部署操作、回退操作等等。

配置中心

配置中心包括配置版本管理、增删改查配置、敏感配置统一加密（数据库信息）、节点配置、配置同步、配置推送等功能

接口框架

微服务提倡轻量级的通信方式，一般采用HTTP/REST或RPC方式统一接口协议。同时可能还需要统一接口传送的数据格式，并遵循特定的规范。

API网关

系统拆分微服务后，外部系统访问系统时并不需要关注微服务的职责分工和边界，所以需要一个统一的网关提供服务，并统一接入鉴权、权限、传输加密、请求路由、流量控制等功能。