2 微服务带来的问题及解决方案分析

2-1 微服务架构带来的问题

2-2 微服务之间如何通信

 

Rest API：rest描述的就是在网络中，客户端和服务端的一种交互的形式，如果以http协议为例，就是以http来实现rest风格的API。

上图BAD里三种比较常见的URL不属于rest风格的API，而下面GOOD中的4种URL属于rest风格的API，区别在于BAD中的API有

各种动作比如get，list等，而GOOD中的API则有各种各样的请求方式，如GET，POST等，而把需要做的事情放到参数中

RPC：

 

 

上图是比较常见的RPC的方案，微服务间通信使用最多的方式就是RPC通信

MQ：消息队列，比如发布订阅的模式，可以选择用MQ来实现

 

首先需要确定微服务之间通信是同步I/O,还是异步I/O,是长链接还是短链接，单线程还是多线程，线程的调度算法的性能是怎样的。第二个要考虑的是序列化的方式，分为可读的和二进制的，可读的比如JSON，二进制的是不可见的。序列化的效率会影响RPC通信的效率。多语言支持，如果我的应用由多种语言组成，就需要考虑支持多种语言的RPC框架。服务端治理，比如说有没有服务发现和服务监控等等，拥有服务治理的RPC框架一般支持集群的部署以及服务的高可用，如果没有的话，这些功能就需要自己实现。

Dubbo是阿里巴巴开源的RPC框架，下面看一下这么模型，上图中蓝色的两个箭头代表服务初始化时做的工作，代表的是服务的提供者和使用者所做的事情，他们都注册自己到注册中心比如zookeeper，第三步中注册中心会返回服务提供者的地址给消费者，如果服务提供者地址发生变化，注册中心会把新的中心给到消费者。第4部消费者会根据负载均衡算法从服务提供者中选择一个提供者进行调用，当调用失败的时候，它会在选择另外一个服务提供者。图中实线表示的同步的调用，虚线表示异步的调用。服务的消费者和提供者会在内存中累计服务调用的次数，并且定时将调用的信息发送到监控中心。虚线的部分都是Dubbo为我们做好了的，也就是说它有着比较完善的服务治理。

 

Motan是新浪微博开源的RPC框架，它的服务提供方式RPC server，服务调用方是RPCclient，还有服务注册中心Registry三个角色，它的流程与Dubbo相同，同时也提供服务治理的功能，同时支持分布式高可用以及负载均衡。

 

Thrift是由facebook开源的RPC框架，是一个跨语言的RPC框架，上图中最下面它需要定义一个PAI负责的定义文件，然后会通过thrift来生成这个文件对应的各种语言的代码，生成之后我们的服务的提供者和消费者都需要把这个代码引进去，服务端实现接口，消费者根据API的存根直接调用，目前支持的语言非常多，比如常见的C++，java，python，rubby，C#等。thrift并没有服务治理相关的东西，

 

GRPC是谷歌开源的RPC框架， 与Thrift类似，也支持跨语言通信。

 

 

2-3 服务发现、部署更新和扩容

        首先我们说一下服务发现，不管是微服务还是传统服务，绝大部分对外的表现都是IP加端口的形式，比如说web服务就是这样，所以说服务发现的本质是让客户端或者调用者如何发现服务的提供者的IP和端口号。首先我们看一下传统服务是如何进行服务发现的，上图中，虚线的部分是一个服务器，10.155.10.5，目前在这上面运行了两个tomcat，是同一个服务运行了两个实例，分别暴露了8081和8082端口，左边把域名通过DNS解析，在Nginx里面配置这两台服务器的IP和端口，通过一个负载均衡策略，比如轮询，依次访问的到右边的服务，这是我们传统服务的服务发现的过程。这种方式如果服务器很多，运维的压力比较大。

 

 

      首先说客户端发现，最下面有一个注册中心，当微服务启动之后，都会把自己暴露的ip和端口号告诉注册中心，然后第二步客户端通过查询注册中心所注册的服务来得知我们服务提供者的ip和端口号列表，然后通过本地的负载均衡策略来实现对微服务的无差别访问，如果出现一些调用失败的情况，客户端也可以有自己的一些重溯的规则。回想之前讲的微服务通信dubbo和motan，都是有服务治理的RPC的方式，他们的模型和客户端的服务发现非常像，他们都是客户端发现的一种实现。

再来看服务端发现，微服务同样把自己的ip和端口注册到注册中心，这和客户端发现是一样的，但是客户端这次不访问注册中心了，她不需要通过注册中心来访问微服务列表了。而是通过一个固定的ip和域名来访问一个具有服务发现和负载均衡的服务，再将请求发给后端的具体服务，再将应答回传到客户端，这个服务在中间起到一个类似于代理人的作用。它会从注册中心获取到具体微服务列表，然后维护到自己的内部，当客户端请求微服务的时候，它会知道，客户端应该请求的这个服务对应哪些实例在运行，通过自己的负载均衡算法来选择一个后端。

 

 

   

对于服务的部署，更新和扩容来说，上图中，是传统的服务部署的方式。为了保证高可用，一般在服务更新的时候，先下线一台服务器，然后在代码更新之后，再重新上线，同样上线另一台服务器也是这样。如果自动化做的不够好的话，这些都需要人工的参与，更新，上下线的成本可想而知。对于扩容，其实跟部署的难度是差不多的，需要找到空闲的机器，复制程序，复制tomcat，找到可用的端口，复制nginx，如果服务巨多，扩容上下线非常频繁，这个时候运维的压力就会比较大。这个时候出现了服务编排，它包括了我们之前讲过的服务发现，部署，更新和扩缩容以及其它功能