在本文中，阿里云技术专家李斌从微服务架构、如何利用Spring Cloud和Docker构建微服务应用、微服务应用部署到阿里云容器服务三部分分享了基于Docker的微服务实战经验。在演讲中，李斌不仅详细介绍了微服务、Spring Cloud、服务发现模式等概念，并且对部分配置代码也进行了详解。
以下为现场分享观点整理。
微服务架构
单体应用VS微服务
微服务顾名思义就是一些小服务，与之相对应的是单体应用。上图左侧四个模块是单体应用的架构、右侧四个模块代表着微服务架构，很多个微服务组合在一起形成大的应用，通过接口对外提供服务，服务之间通过远程调用，当更新其中一个微服务时，其他微服务不受任何影响。单体应用和微服务对比而言：微服务的特点是解耦的、自制的、协同的，而对于单体应用是大而全；微服务应用只完成一个功能，并达到最好，而单体应用通常包含多种能力；微服务对外提供的是服务接口，而单体应用提供的是模块接口；此外，微服务允许尝试新技术，如不同的语言，但服务内部变更不影响其他服务，而单体应用现有着成熟技术和中间件，但模块级别变更会导致应用更新；微服务具有较强的水平扩展能力，而单体应用垂直扩张能力很强。
容器技术
容器技术实际是一种虚拟化技术，它有点类似于虚拟机，但和虚拟机又有差别，它比虚拟机的虚拟化方式轻量很多。因此它带来的效果就是快，这里快包含两层意思：一是Docker启动速度特别快；二是容器技术上手十分快，十分易学。上图是Docker官方的架构图，可以看到底层操作系统是共享的，每一个Docker镜像只打包与其他镜像不同的代码、插件等，这种差异化的打包方式使得镜像的大小很小，通常一个容器镜像只有几十兆左右。
尽管Docker的表现形式是打包和运行环境，但Docker实际上是标准化的构建、交付、运维手段。在软件交付的生态链中，Docker就像集装箱一样，它将软件的交付与运维标准化，表现在以下几个方面：
- 可组合，在同一环境之中，每个Docker之间是相互隔离的，因此在同一个环境中可以跑任意程序而不发生冲突。
- 可移植，在不同环境中，同一个镜像运行表现完全一致。
- 动态，Docker的可组合性和可移植性/超快的运行速度以及标准化的模式，使得Docker可以动态管理。
Spring Cloud
Spring Cloud是对常见的分布是应用模式的封装，通常封装的内容包括：
- 配置管理：Config Server
- 服务发现：Eureka
- 断路器：Hystrix
- 智能路由：Zuul
这几者之间的关系如上图所示。在单体应用情况下，服务发现不存在任何困难，但微服务化之后，复杂的结构中寻找到服务的访问端点以及服务之间通信、对外提供服务以及监控海量服务都将面临着新的难题。
利用Spring Cloud和Docker构建微服务应用
服务发现
在动态环境中服务发现分为两种模式：一是客户端发现模式；另一个是服务器端发现模式。两种模式的差别在于：服务端发现模式是通过一个负载均衡器作为一个单点进行服务发现；客户端发现模式中，负载均衡的功能由调用服务的服务自行承担，负载均衡的单点也随之消失。
服务发现大致分为三种类型，第一种类型是：DNS 。所有的应用都支持域名发现，如上图所示，Server A访问Server B时，只需要知道Server B域名，就可以确保访问无差错。DNS Alias类似，用于访问多个实例中的其中一个实例，DNS Alias最大的好处是应用无需做任何改动，就可以直接使用。
在Docker 1.1版本之后，已支持DNS服务发现模式，如果应用运行在Docker内，同时不想做任何改动的情况下，可以选择DNS服务发现方式。但是，DNS有时会存在延迟现象或者TTL问题。
第二种服务发现类型是Spring Cloud中的Eureka类型。Eureka是一种客服端负载均衡的发现模式，Eureka本身是一个服务发现的Server，它不负责负载均衡，它仅是内存了所有的服务端点，当请求来临时，告知请求所需的服务端点。
如上图框黑色代码所示，可以通Docker Compose模板实现在Docker中运行Eureka。
第三种服务发现类型是阿里云容器服务提供的简单路由服务。简单路由服务是服务端发现模式，在集群内部内置了负载均衡器，外部请求通过负载均衡器找到后面的服务。
三种服务发现模式相比较各具优缺点，Eureka的优点在于功能完善，缺点是仅支持Java语言，并且对代码有一定侵入；DNS的优点在于它与语言无关，支持广泛，同时代码不必做改动，并且Docker 1.10版本以上原生支持，缺点在于存在TTL和客户端Cache问题；简单路由服务的优点在于与语言无关，支持灵活的负载均衡策略，同时避免TTL问题，并且支持健康检查，缺点是有少量的路由开销。
服务间通信
服务间通信首先需要在服务之间定义清晰的服务接口，接口之间可以用同步方式或异步方式表现出来，例如同步方式的REST接口。在Spring Cloud中封装了RestTemplate和FeignClient两类同步接口；异步机制通常采用消息队列。
服务之间的通信对于微服务而言并不是特别新的点，原有的同步和异步通信方式都适合微服务，具体使用时需要根据应用的特点进行选择。
服务接入和路由
经过服务发现和服务通信之后，理论上服务可以正常运行起来了。上图显示的是，服务运行时，外部服务访问的示意图。
手机应用想访问后台时，需要三个内容，第一个内容需要显示产品、产品的名称、图片；第二个内容是根据用户访问历史的推荐；第三个是该产品的其他用户的评论。在后台三个内容对应着三个服务，每个服务中又存在多个实例，当手机应用自行判断访问实例时，负载过重。为了减轻这种负载，手机应用可以通过API Gateway代理。当请求到达API Gateway时，API Gateway在后台获取所需内容后，在API Gateway中进行组合，生成新的结果返回个手机应用。
在Spring Cloud中，API Gateway可以通过Zuul实现。上图右侧代码是Zuul配置，这是Spring Cloud配置文件的部分代码，在Zuul中配置了三个规则：product、recommendation、comment。
左侧是Docker compose 模板在容器服务上部署Zuul的代码，通过指定Zuul镜像、确定端口、给定相应的实例以及其他一些细节，即可以完成Zuul部署。Zuul镜像本身是一个非常固定的镜像，镜像打包后，无需修改即可使用。
阿里云简单路由服务同样可以实现API Gateway，通过在阿里云容器服务的部署模板中，对每个服务声明对外部署的端点状况，例如上图显示的product中的aliyun.routing.port_5557，将容器的5557端口描述成Product.image域名，在部署之后，可以在容器控制台中看到该链接，点击该链接既可产品的信息，通过简单路由服务，将外部流量导入内部进行服务发现。
配置管理
在Spring Cloud中，配置管理可以使用Config Server完成，在Config Server中，具体的配置信息存在代码仓库中，配置服务直接访问代码仓库。当发生变更时，将变更信息push到代码仓库中即可，所有应用运行时只会连接配置服务器，具体步骤如上图所示。Config Server同样可以部署在阿里云容器上。
此外，在阿里云上，还可以利用OSS Volume同步配置信息。
监控和日志
在Spring Cloud中提供了Spring Actuator，Spring Actuator自动在应用中开辟了HTTP/JSON的端点，通过HTTP/JSON提供应用的健康信息，用于第三方监控工具输入。对于应用级别的监控，通常是将第三方工具输入聚合。同时，阿里云容器服务提供了日志自动收集和分析，以及云监控。
服务部署和发布
单机运行Docker和企业内实际使用是有很大的差异的，企业内实际使用时，需要考虑安全配置、调度、底层集群管理等因素。这些配置、调度的工作可由Docker的调度工具完成，目前常用的编排工具有Docker Swarm、Kubernetes等。
阿里云的容器服务（Container Service）提供了高性能可伸缩的容器应用管理服务，支持在一组云服务器上通过Docker容器来进行应用生命周期管理。开发人员只需要专注于构建代码，然后将代码编译好的镜像存入中心镜像仓库中；镜像仓库中的镜像会被部署到各环境中，如运行环境、开发环境、测试环境等。通过CaaS平台，将Build、Ship、Run与Devops结合，
使用者只需要在有代码的情况下就可以发布或更新应用。常见的发布方式有蓝绿发布、金丝雀发布、灰度发布。不同发布方式所追求的目标是在应用升级过程中，最大限度地对外提供服务。
完整示例
上图是Docker和Spring Cloud在阿里云容器服务上运行微服务的示例。该示例包含两个可用区，每个可用区内的ECS运行包含产品、推荐、评论等微服务，再通过API Gateway对外部署，可用区外部有一个负载均衡器，用于负载均衡多个可用区的网关，每个可用区内都配置了Eureka和Config server，不同的可用区内分服务可以相互访问不同的Eureka和Config server。更多示例配置细节，请参考云栖社区文章：在阿里云容器服务上开发基于Docker的Spring Cloud微服务应用。
