（二）微服务带来的问题及解决方案

目录

1、微服务间如何通讯？

1.1、从通讯模式角度考虑

1.2、从通讯协议角度考虑

2、微服务如何发现彼此？

2.1、服务发现本质

2.2、传统服务的服务发现：

2.3、客户端发现 

2.4、服务端发现

3、微服务如何部署？更新？扩容？ 

3.1、一个新服务部署的流程

3.2、更新

3.3.、扩容

 

---

 

 

1、微服务间如何通讯？

 问题描述：

    在什么情况下服务与服务之间需要通讯，肯定是调用它的什么接口或者是依赖于它的什么样数据、什么样功能，在单体架构中，这种情况是比较少见的，因为一个系统在一个应用里已经完成了相关的功能，当然也不排除有些功能和接口是来源于其他系统的，在单体架构中我们常用的方案有几种，一个是直接把其他系统的链接拿过来，把内容嵌入到页面里，还有可能是使用TCP Client来调用对方的TCP接口从而拿到返回的数据，这是在单体架构中两个比较常见的方案。但是微服务就要系统的考虑一下，因为微服务特别的多，并且他们之间的调用非常频繁的，所以我们必须事先设计好，微服务之间怎么样才能高效、快捷方便地通讯。

 

1.1、从通讯模式角度考虑

一对一还是一对多？同步还是异步？

 

1.2、从通讯协议角度考虑

▶ REST API

▶ RPC（微服务通讯使用的最多的一种）
  ①如何选择一个RPC框架

    ● I/O — 是同步的I/O还是异步非阻塞的NIO，是长连接（只要连接上了就会尽量保持连接状态，而不会去主动断掉）还是短链接（一次请求响应完成之后就关闭连接，如HTTP）；

    ● 线程调度模型的 — 是单线程还是多线程，线程的调度算法的性能怎样；

    ● 序列化方式 — 可读的（XML、JSON）还是二进制（人工不可见的，比如JDK自带的序列化）；注意：序列化的效率直接影响了RPC通讯的效率，序列化和反序列化需要的时间、序列化之后的大小；

    ● 多语言支持 — 是否需要多个语言相互通讯；

    ● 服务治理 — 有没有服务发现、服务监控。

 

  ②流行的RPC框架(具体对比参看四种流行的RPC框架（Dubbo/Motan/Thrift/Grpc）)

     ● Dubbo（阿里很早就开源的）  / Dubbox(当当自己维护的一套Dubbo)

     ● Motan（新浪微博，开源的）

     ● Thrift（Apache的）

     ● Grpc（谷歌的）

     ● ...

▶ MQ（用的较少，适合于发布订阅模式）

 

 

2、微服务如何发现彼此？

   问题描述：Dubbo提供了一种服务，web端Dubbo的消费者是要对Dubbo的提供者进行一个发现的，它的发现是通过Zookeeper或者是一些其他Dubbo支持的类似于K-V的存储，类似于有一个中间人，服务的提供者把提供者的消息告诉这个中间人，服务的消费者去中间人那拿服务提供者的地址，就能实现一个服务发现。如果用Dubbo，就直接选用Zookeeper就好了，但是微服务，它有各种各样的语言，各种各样的通讯方式，所以微服务之间如何彼此发现成为了我们要提前设计和解决的问题。

 

 2.1、服务发现本质

    不管是传统服务还是微服务，对外接口的表现都是通过IP+端口的形式，比如web服务对外的形式就是：服务所运行的机器的IP+服务所暴露的端口。所以，服务发现的本质就是让客户端或者调用者知道服务提供者的IP和端口号。

 

 2.2、传统服务的服务发现：

    上图中，右边虚线部分是一个实体的服务器，在它上面运行了两个Tomcat（同一个服务运行了两个实例），Tomcat1暴露了8080端口，Tomcat2暴露了8081端口；左边客户端访问了一个域名，通过DNS解析到Nginx，前端的Nginx反向代理，在Nginx里边就要配置这两台服务器的IP和端口，Nginx有一个负载均衡的策略，比如说轮询，它会依次访问到右边的两个服务，这就是传统服务的服务发现的一个过程。

    不过这个“发现”应该是带引号的，因为它其实没有真正的去发现什么内容，而是在Nginx上把服务的提供者写“死”了，只是这些配置文件的更新都需要运维人员来手动操作。

    如果是微服务，这样来做也是可以实现的，但是当微服务越来越多，这个工作量是相当大的，运维人员也会非常痛苦，所以微服务需要一种服务发现的机制。微服务的发现有两种机制：客户端发现、服务端发现。

 

 

2.3、客户端发现 

    上图中，有一个注册中心，当微服务启动之后，所有的微服务会把自己暴露的IP和端口号“告诉”注册中心，客户端通过查询注册中心中所注册的服务来得知微服务提供者的IP和端口列表，通过本地的负载均衡的策略来实现对微服务的无差别访问，如果出现一些调用失败的情况，客户端也有自己的一些重试的规则。

     可以看一下我 下一篇谈到的微服务通讯方式RPC框架中的Dobbo和Motan，它们都是有服务治理功能的，通过对比可以发现，它们对于服务的发现和客户端发现是十分相似的，也就是说Dobbo和Motan是客服端发现的一种实现。

 

 

 

2.4、服务端发现

    同样的，微服务把自己的服务注册到注册中心，但是此时客户端不再访问注册中心了，也就是不需要通过注册中心得到微服务列表， 而是通过一个固定的IP或域名来访问一个具有服务发现和负载均衡功能的服务，再由它将请求转发给具体服务并且将应答会传到客户端，这个服务在中间起到了一个类似于代理人的作用，它会从注册中心获取到具体的微服务列表，然后维护到自己的内部，客户端在请求一个服务时，它会知道，客户端应该请求的是这个服务对应的哪些实例的运行，并且通过自己的负载均衡算法去选择一个后端，上述过程就是服务端的发现。

 

 

 

3、微服务如何部署？更新？扩容？ 

  3.1、一个新服务部署的流程

    前提：代码写好了，内网测试通过，准备上线；上线肯定需要一台服务器，所以要和运维交涉，哪台服务器比较空闲，可以把服务部署上去，或者说资源都比较吃紧的情况可能要等到新服务器上架之后才能开始部署。

    假如我们得到了一个比较合适的服务器，然后就是告诉运维把我们的哪一个应用copy到服务器上，可能是通过Jenkins脚本或者其他自动化方式，如果是web服务，就需要再copy一个Tomcat，给我们的服务分配一个端口号，这个时候就要查询服务器占用的端口列表，找一个没有被占用的端口修改好，给域名做DNS解析，解析到对应的Nginx，在Nginx里配置好反向代理指向刚刚配置好的Tomcat，这样部署工作就完成了。

 

3.2、更新

     在单实例的情况下做更新操作还是很容易的，替换一下旧代码，重启一下服务就OK了。但是现在稍微重要一点的服务就不可能是单实例的，至少是两个，需要高可用，这样我们在更新代码的时候就需要先下线一台服务器，然后把代码做好更新，然后重启验证没有问题之后再把它上线，同样上线完一个之后，需要把前一个下线，然后重复这样的过程。如果自动化机制做得不够好的话，这些过程都需要人来参与，更新和上线的成本是可想而知的。

 

 

3.3.、扩容

    扩容和部署的难度是差不多的，它得找到空闲的机器，它得copy程序、得copy Tomcat、得找到没被占用的端口号、得修改Nginx，这个过程还是比较复杂的，但是这个在我们的服务数量比较少，上线不太频繁的时候，运维人员还是可以接受的，但是到了微服务就没办法接受了，因为微服务的特征就是服务数量特多，更新上线非常频繁，微服务怎样解决服务发现、部署、更新以及扩充容的问题呢？这里就出了一个新名词——服务编排。

    服务编排没有明确的定义，但是这个名词提出的意义就是简化服务发现、部署、更新以及扩缩容等一系列操作。如果一个框架或者一个平台说它自己具有服务编排的功能 或者说 解决了服务编排的问题，我们就能大概的了解到他有哪些功能了。‘

’以下就是几个流行的服务编排工具：

● Mesos  —— Apache的

●Docker Swarm  —— Docker的

●Kubernetes  —— Google的