服务化？

一、背景

学过web开发的同学大多知道MVC设计模式，即通过Model-View-Controller分离和组合的方式，分解整个web后台的处理流程。起初项目包含的功能不多，开发人员可以直接在项目里实现MVC，快速迭代。但是当需要多团队并行开发多项功能时，问题就出现了：

• 某个小模块的功能缺陷可能导致整个项目崩溃

• 多个模块代码耦合在一起，代码修改和调试成本越来越高

• 不同模块由不同的团队开发，很多基础的功能重复实现，代码冗余度高

• ....

如此庞大的工程通常称为单体应用，为减小代码bug的影响面，许多初创公司一般采用合并发布和回滚的策略，即将多个待发布功能聚合在一起发布，出现故障时一次性回滚。

二、服务化

为了解决上述单体应用存在的问题，业界普遍的做法是拆分单体应用，将其拆分成一个个独立部署的、可运维的功能模块，即微服务。这样，模块代码影响的范围局限于自身服务，调试和定位问题十分方便，基础的功能均由对应的服务提供，整个应用的代码冗余度低。

但是，应用拆分也带来了一系列的问题：

• 模块间通信由API调用变为跨进程通信，可能出现网络故障，对方进程挂掉等异常情形

• 被调用模块的配置如ip地址和端口号等可能会变更，如何在调用方动态配置被调用模块

• 请求处理涉及多个服务，如何减小调试和定位问题的复杂度

• 服务实例可能存在多个，如何有效动态扩容和缩容，如何控制请求的流量大小

• ....

针对上述问题，涉及到服务化中的服务调用，服务路由，服务注册，服务发现，服务上下线、服务治理等解决方案，在服务化领域中，服务调用方称为服务消费者，服务被调方称为服务提供者。

1. 服务调用

服务调用意味着服务间的功能交互，服务调用的方式包括同步调用，异步调用，涉及到RPC和消息的序列化。服务调用屏蔽了底层实现的细节，在使用者看来，服务调用和API调用的效果一致。服务调用需要处理网络故障，超时重传，编解码失败，心跳等问题。

2.服务路由

服务提供者可能存在多个实例，需要路由至具体的服务提供者实例。一般在服务消费者中会缓存服务提供者的多个实例信息，调用方采用负载均衡算法选出合适的服务提供者实例，发起服务调用。常见的负载均衡算法包括轮询，随机，加权轮询等。当因为网络原因等故障调用失败时，服务需要路由至其他服务提供者实例进行重试。

3. 服务注册与发现

由于服务提供者的配置信息如服务实例数目，服务实例的ip地址和端口号可能发生变化。传统的通过配置文件设置服务提供者信息的方式无法满足服务提供者的动态配置，需要引入注册中心来保存所有注册的服务信息，供服务消费者查询获取，这样服务消费者只需要固定配置注册中心的地址即可动态获取服务提供者的信息。

如下图所示，服务提供者将服务和方法注册到注册中心，注册中心采用心跳监测服务提供者的存存活。服务消费者向注册中心拉取需要的服务提供者信息，并订阅服务，一旦注册中心监测到服务提供者的信息发生变化，会主动通知服务消费者同步更新服务提供者的信息。服务消费者缓存服务提供者的信息，需要消费服务时，从中选取合适的服务提供者实例，然后发起一次服务调用，获取返回的响应结果。 

4.服务上下线

服务提供者有上线注册到注册中心的情形，自然有主动下线的场景。新服务上线后服务消费者通过注册中心能够感知到新上线的服务实例存在。但服务下线时，下线消息通过注册中心到达服务消费者存在时间间隙，这是若服务消费者继续发起服务调用，服务调用会失败。为了避免这种情形发生，服务下线之前需要先反注册，待注册中心通知所有的服务消费者，确保服务消费者的服务信息更新之后，再下线服务提供者。

5.服务治理

实施服务化之后，出现了大量的服务实例。为了有效地管理与监测服务，需要进行服务治理。一般监控指标包括：

• 服务与服务之间的调用关系

• 服务调用时延

• 服务调用成功率

• 服务的CPU占用率，内存和磁盘消耗等性能指标

• ....

从监控的数据可以了解到请求处理历经的所有服务，每个调用过程的时延，这样可以有针对性地优化处理的某个阶段。另外，服务的性能指标为服务的扩容和缩容提供了量化依据，也可以利用服务调用频率实施服务限流。

关于服务治理还有很多内容，比如服务降级，服务分组，服务熔断等，有兴趣的读者可以自行调研相关资料。

ps:http://blog.csdn.net/xhjcehust/article/details/75209331