微服务近几年发展非常火热，它的架构设计理念引起了一阵大热潮，大部分人认为这是martin fowler提出来了微服务，但事实上微服务概念的历史要早得多，也不是martin fowler创造出来的，martin fowler只是将微服务进行阐述，它推动了微服务快速发展，现在简单梳理一下微服的历史及搭建微服务的基础设施。

1、发展史

• 2005年，Dr.peter rodgers在web services edge 大会上提出“Micro-WEB-Services”的概念。
• 2011年：一个软件架构工作组使用了“microservice“一词来描述一种架构模式。
• 2012年：thoughtWorks的james Lewis针对微服务概念在QCon San Francisco 2012发表演讲。
• 2014年：James Lewis和Martin Fowler合写了关于微服务的一篇学术性文章，详细阐述了微服务。

2、微服务配套

   每项微服务基础设施都是一个平台，一个系统，一个解决方案，如果要自己实现，其过程和做系统类似，都需要经过需求分析，架构设计、开发测和部署上线等步骤，接下来介绍一下微服务的基础设施。

* 自动测试

  微服务将原本大一统的系统拆分为多个独立运行的微服务，微服务之间的接口数量大大增加，并且微服务提倡快速交付，版本周期短，版本更新快。如果每次更新都靠人工回归整个系统，则工作量大，效率会比较低，达不到快速交付的目的，因此必须通过自动化测试系统来完成绝大部分测试回归工作。自动化测试涵盖的范围包括代码级的单元测试，单个系统级的集成测试、系统间接口测试，理想情况是每类测试都自动化。如果因为团规模和人力的原因无法全面覆盖，至少要做到接口测试自动化。

* 自动化部署

  相比大一统的系统，微服务需要部署的节点增加了几倍甚至十几倍，部署的频率也会大幅度提升，综合算下来，微服务的次数是大一统系统部署次数几十倍。那么大量的部署操作，如果继续用人工手工处理，需要投入大量的人力，且容易出错，因此需要自动化部署系统来完成部署操作。自动化部署包括版本管理、资源管理、部署操作、回退操作等功能 。

* 配置中心

  微服务的节点数量非常多，特别大厂，通过人工登陆每台机器手工修改，效率低，容易出错，特别是在部署或排障时，需要快速增删改配置，人工操作显然是不行的。除些以外，有的运行期配置需要动态修改并且及时生效，人工操作是无法做到的。综合以上分析，微服务需要一个统一的配置中心来管理所微服务节点的配置。配置中包括版本管理、节点管理，配置同步，配置推送等功能。

* 接口协议

  微服务提倡轻量级的通信方式，一般是http/rest或者RPC方式统一接口协议。但在实践过程中，光统一接口协议还不够，还需要统一接口传的数据格式，例如：

{
      "requestId":10086
      "time":"2018-12-12 00:00:00"
      "caller":"VIPSHOP"
      "serviceName":"com.test.ServiceName"
      "method":"update"
      "param":{
           "userId": "2018-12-12 00:00:00"
       }
      "sign":"1fdfdsfdfdfsfdfdsfdsfdsfd"
}

我们需要指定接口协议为http/rest，但这还不够，还需要指定数据格式采JSON，并且JSON的数据都遵循以上规范。接口框架不是一个可运行的系统，一般以库或者包的形式提供给所有服务调用者。

*服务发现

  微服务种类和数量很多，如果这些信息全部通过手工配置的方式写入各个服务节点，着先配置工作量很大，配置文件可能要配置几百上千行，几十个节点加起来后配置项项就是几万甚至更多，人工维护这么大的数据量的配置项将是一场空难；其次是微服务节点经常变化，可能是由于扩容导致节点增加，也可能是故障处理时隔离掉一部分节点，还可能是采用灰度升级，先将一部分节点升级到新版本，然后让老版本同时运行。不管哪一种情况，我们都希望节点的变化能够及时同步到所有其它依赖的微服务。如果采用手工配置，是不要能做到实时更改生效的。因此，需要一套服务发现的系统来支撑服务的自动注册和发现。服务发现主要有两种实现方式 ：自理式和代理式。

• 自理式
    自理式就是指每个微服务自己完成服务注册和发现，自理服务发现实现比较简单，因为这部分的功能一般通过统一的程序库或者程序包提供给各个微服务调用，而不会每个微服务都承担了服务发现的功能，访问压力分散到了各个微服务节点，性能和可能性不存在明显的压力和风险。
• 代理式
    代理式就是指微服务之间有一个负载均衡系统，由负载均衡系统来完成微服务之间的服务发现。代理式看起来更加清晰，微服务本身的实也简单了很，但实际上这个方案风险较大，第一个风险当负载均衡系统故障，就会影响微服务之间的调用。二是性能风险，所有的微服务之间的调用流量都要经过负载均衡系统，性能压力随着服务数量和流量增加而不断增加，最后成为性能瓶颈。
    不管理是自理式还是代理式，服务发现的核心功能就是服务注册，注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到注册表，然后由微服务或者负载均衡系统到注册表查询可用服务。

* 服务路由

  有了服务发现后，微服务之间能够方便地获相关配置信息，但具体进行某次调用请求时，我们还需要从所有符合条件的可用微服务节点中挑选出一个具体的节点发起请求，这就是服务路由需要完成的功能。服务路由和服务发现是非常紧密相关，服务路由一般不会设计成一独立的系统，通常情况下是和服务发现放在一起实现，服务路由算法有，随机路由，轮询路由，最小压力路由，最小连接数路由等。

* 服务监控

  系统拆分为微服务后，单个系统服务故障的概率真变小，故障影响范围也减少，但微服务的节数量大大增加，从整体上来看，系统中某个微服务出故障的概率会大增加，如果处理不及时，就会扩散导致系统中很节点故障，如果一出故障就由人工来处理，会处理速度慢，则故障就很扩散，所以我们需要服务容错能力，常见的服务容错包括重试，流控，服务隔离。通常情况下，服务容错会集成在服务发现和服务路系统中。

* 服务监控

系统拆分为微服务后，节点数大增加，导致需要监控的机器、网络、进程、接口调用数等，监控的数量大增加；同时一旦发生故障，需要根据各类信息快速定位，这两个目标如果靠人力去完成，是不太现实的。通常情况下，服务监控需要搜集并分析大量的数据，因此建议做成独立系统，而不要集成到服务发现、API网关系统中。

* 服务跟踪

  服务监控可以做到服务节点级的监控和信息收集，但如果我们需要跟踪某一个请求在服务中的完整路径，服务监控是难以实现的，服务监控和服路踪的区别为宏观和微观的区别。例如：A服务调用B服务，B返回数据，服务监控会记录请求次数，响应时间平均值、响应最高值，错误码分布这些信息。而服务跟踪会记录其中某次请求的发起时间、响应时间 、响应错误码，请求参数、返回的数据等信息。
  以上是做微服务需要的一些基础设施，当然不同公司发展层次不一样，可以选择性来实现部分设施。