基于Docker的微服务架构实践前言基于Docker的容器技术是在2015年

基于Docker的微服务架构实践前言基于Docker的容器技术是在2015年的时候开始接触的，两年多的时间，作为一名Docker的DevOps，也见证了Docker的技术体系的快速发展。本文主要是结合在公司搭建的微服务架构的实践过程，做一个简单的总结。希望给在创业初期探索如何布局服务架构体系的DevOps，或者想初步了解企业级架构的同学们一些参考。Microservice和Docker对于创业公司的技术布局，很多声音基本上是，创业公司就是要快速上线快速试错。用单应用或者前后台应用分离的方式快速集成，快速开发，快速发布。但其实这种结果造成的隐性成本会更高。当业务发展起来，开发人员多了之后，就会面临庞大系统的部署效率，开发协同效率问题。然后通过服务的拆分，数据的读写分离、分库分表等方式重新架构，而且这种方式如果要做的彻底，需要花费大量人力物力。个人建议，DevOps结合自己对于业务目前以及长期的发展判断，能够在项目初期使用微服务架构，多为后人谋福。随着Docker周围开源社区的发展，让微服务架构的概念能有更好的一个落地实施的方案。并且在每一个微服务应用内部，都可以使用DDD（Domain-DriveDesign）的六边形架构来进行服务内的设计。关于DDD的一些概念也可以参考之前写的几篇文章：领域驱动设计整理——概念&架构、领域驱动设计整理——实体和值对象设计、领域服务、领域事件。清晰的微服务的领域划分，服务内部有架构层次的优雅的实现，服务间通过RPC或者事件驱动完成必要的IPC，使用APIgateway进行所有微服务的请求转发，非阻塞的请求结果合并。本文下面会具体介绍，如何在分布式环境下，也可以快速搭建起来具有以上几点特征的，微服务架构withDocker。服务发现模式如果使用Docker技术来架构微服务体系，服务发现就是一个必然的课题。目前主流的服务发现模式有两种：客户端发现模式，以及服务端发现模式。客户端发现模式客户端发现模式的架构图如下：客户端发现模式的典型实现是Netflix体系技术。客户端从一个服务注册服务中心查询所有可用服务实例。客户端使用负载均衡算法从多个可用的服务实例中选择出一个，然后发出请求。比较典型的一个开源实现就是Netflix的Eureka。Netflix-EurekaEureka的客户端是采用自注册的模式，客户端需要负责处理服务实例的注册和注销，发送心跳。在使用SpringBoot集成一个微服务时，结合SpringCloud项目可以很方便得实现自动注册。在服务启动类上添加@EnableEurekaClient即可在服务实例启动时，向配置好的Eureka服务端注册服务，并且定时发送以心跳。客户端的负载均衡由NetflixRibbon实现。服务网关使用NetflixZuul，熔断器使用NetflixHystrix。除了服务发现的配套框架，SpringCloud的Netflix-Feign，提供了声明式的接口来处理服务的Rest请求。当然，除了使用FeignClient，也可以使用SpringRestTemplate。项目中如果使用@FeignClient可以使代码的可阅读性更好，RestAPI也一目了然。服务实例的注册管理、查询，都是通过应用内调用Eureka提供的RESTAPI接口（当然使用SpringCloud-Eureka不需要编写这部分代码）。由于服务注册、注销是通过客户端自身发出请求的，所以这种模式的一个主要问题是对于不同的编程语言会注册不同服务，需要为每种开发语言单独开发服务发现逻辑。另外，使用Eureka时需要显式配置健康检查支持。服务端发现模式服务端发现模式的架构图如下：客户端向负载均衡器发出请求，负载均衡器向服务注册表发出请求，将请求转发到注册表中可用的服务实例。服务实例也是在注册表中注册，注销的。负载均衡可以使用可以使用Haproxy或者Nginx。服务端发现模式目前基于Docker的主流方案主要是Consul、Etcd以及Zookeeper。ConsulConsul提供了一个API允许客户端注册和发现服务。其一致性上基于RAFT算法。通过WAN的Gossip协议，管理成员和广播消息，以完成跨数据中心的同步，且支持ACL访问控制。Consul还提供了健康检查机制，支持kv存储服务（Eureka不支持）。Consul的一些更详细的介绍可以参考之前写的一篇：Docker容器部署Consul集群。EtcdEtcd都是强一致的（满足CAP的CP），高可用的。Etcd也是基于RAFT算法实现强一致性的KV数据同步。Kubernetes中使用Etcd的KV结构存储所有对象的生命周期。关于Etcd的一些内部原理可以看下etcdv3原理分析ZookeeperZK最早应用于Hadoop，其体系已经非常成熟，常被用于大公司。如果已经有自己的ZK集群，那么可以考虑用ZK来做自己的服务注册中心。Zookeeper同Etcd一样，强一致性，高可用性。一致性算法是基于Paxos的。对于微服务架构的初始阶段，没有必要用比较繁重的ZK来做服务发现。服务注册服务注册表是服务发现中的一个重要组件。除了Kubernetes、Marathon其服务发现是内置的模块之外。服务都是需要注册到注册表上。上文介绍的Eureka、consul、etcd以及ZK都是服务注册表的例子。微服务如何注册到注册表也是有两种比较典型的注册方式：自注册模式，第三方注册模式。自注册模式Self-registrationpattern上文中的Netflix-Eureka客户端就是一个典型的自注册模式的例子。也即每个微服务的实例本身，需要负责注册以及注销服务。Eureka还提供了心跳机制，来保证注册信息的准确，具体的心跳的发送间隔时间可以在微服务的SpringBoot中进行配置。如下，就是使用Eureka做注册表时，在微服务（SpringBoot应用）启动时会有一条服务注册的信息：com.netflix.discovery.DiscoveryClient:DiscoveryClient_SERVICE-USER/{your_ip}:service-user:{port}:cc9f93c54a0820c7a845422f9ecc73fb:registeringservice...同样，在应用停用时，服务实例需要主动注销本实例信息：2018-01-0420:41:37.290INFO49244---[Thread-8]c.n.e.EurekaDiscoveryClientConfiguration:Unregisteringapplicationservice-userwitheurekawithstatusDOWN2018-01-0420:41:37.340INFO49244---[Thread-8]com.netflix.discovery.DiscoveryClient:ShuttingdownDiscoveryClient...2018-01-0420:41:37.381INFO49244---[Thread-8]com.netflix.discovery.DiscoveryClient:Unregistering...2018-01-0420:41:37.559INFO49244---[Thread-8]com.netflix.discovery.DiscoveryClient:DiscoveryClient_SERVICE-USER/{your_ip}:service-user:{port}:cc9f93c54a0820c7a845422f9ecc73fb-deregisterstatus:200自注册方式是比较简单的服务注册方式，不需要额外的设施或代理，由微服务实例本身来管理服务注册。但是缺点也很明显，比如Eureka目前只提供了Java客户端，所以不方便多语言的微服务扩展。因为需要微服务自己去管理服务注册逻辑，所以微服务实现也耦合了服务注册和心跳机制。跨语言性比较差。第三方注册模式Thirdpartyregistrationpattern第三方注册，也即服务注册的管理（注册、注销服务）通过一个专门的服务管理器（Registar）来负责。Registrator就是一个开源的服务管理器的实现。Registrator提供了对于Etcd以及Consul的注册表服务支持。Registrator作为一个代理服务，需要部署、运行在微服务所在的服务器或者虚拟机中。比较简单的安装方式就是通过Docker，以容器的方式来运行。三方注册模式的架构图如下：通过添加一个服务管理器，微服务实例不再直接向注册中心注册，注销。由服务管理器（Registar）通过订阅服务，跟踪心跳，来发现可用的服务实例，并向注册中心（consul、etcd等）注册，注销实例，以及发送心跳。这样就可以实现服务发现组件和微服务架构的解耦。Registrator配合Consul，以及ConsulTemplate搭建服务发现中心，可以参考：ScalableArchitectureDRCoN:Docker,Registrator,Consul,ConsulTemplateandNginx。此文示例了Nginx来做负载均衡，在具体的实施过程中也可以用Haproxy或其他方案进行替代。小结除了以上几种做服务发现的技术，Kubernetes自带了服务发现模块，负责处理服务实例的注册和注销。Kubernetes也在每个集群节点上运行代理，来实现服务端发现路由器的功能。如果编排技术使用的k8n，可以用k8n的一整套Docker微服务方案，对k8n感兴趣的可以阅读下Kubernetes架构设计与核心原理。在实际的技术选型中，最主要还是要结合业务、系统的未来发展的特征进行合理判断。在CAP理论中。Eureka满足了AP，Consul是CA，ZK和Etcd是CP。在分布式场景下Eureka和Consul都能保证可用性。而搭建Eureka服务会相对更快速，因为不需要搭建额外的高可用服务注册中心，在小规模服务器实例时，使用Eureka可以节省一定成本。Eureka、Consul都提供了可以查看服务注册数据的WebUI组件。Consul还提供了KV存储，支持支持http和dns接口。对于创业公司最开始搭建微服务，比较推荐这两者。在多数据中心方面，Consul自带数据中心的WAN方案。ZK和Etcd均不提供多数据中心功能的支持，需要额外的开发。跨语言性上，Zookeeper需要使用其提供的客户端api，跨语言支持较弱。Etcd、Eureka都支持http，Etcd还支持grpc。Consul除了http之外还提供了DNS的支持。安全方面，Consul，Zookeeper支持ACL，另外Consul、Etcd支持安全通道Https。SpringCloud目前对于Eureka、Consul、Etcd、ZK都有相应的支持。Consul和Docker一样，都是用Go语言实现，基于Go语言的微服务应用可以优先考虑用Consul。服务间的IPC机制按照微服务的架构体系，解决了服务发现的问题之后。就需要选择合适的服务间通信的机制。如果是在SpringBoot应用中，使用基于Http协议的RESTAPI是一种同步的解决方案。而且Restful风格的API可以使每个微服务应用更加趋于资源化，使用轻量级的协议也是微服务一直提倡的。如果每个微服务是使用DDD（Domain-DrivenDesign）思想的话，那么需要每个微服务尽量不使用同步的RPC机制。异步的基于消息的方式比如AMQP或者STOMP，来松耦合微服务间的依赖会是很好的选择。目前基于消息的点对点的pub/sub的框架选择也比较多。下面具体介绍下两种IPC的一些方案。同步对于同步的请求/响应模式的通信方式。可以选择基于Restful风格的Http协议进行服务间通信，或者跨语言性很好的Thrift协议。如果是使用纯Java语言的微服务，也可以使用Dubbo。如果是Sprin