2、Docker 可以很好地和微服务结合起来。从概念上来说，一个微服务便是一个提供一整套应用程序的部分功能，Docker 便可以在开发、测试和部署过程中一直充当微服务的容器。甚至生产环境也可以在 Docker 中部署微服务。
3、在云服务提供商之间移植，大多数的云主机提供商已经全面支持 Docker。对于开发人员来说，这表示你可以很方便地切换云服务提供商，当然也可以很方便地将你本地的开发环境移动到云主机上，不需要本地上配置一次运行环境、在云主机上还配置一次运行环境。全面部署 Docker (Docker here and Docker there) 作为标准运行环境可以极大地减轻应用上线时的工作量和产生 BUG。
4、API 端，API 是应用之间的粘合剂，一个合格开发者肯定使用过别人提供的 REST API，或者自己开发过 REST API。需要指出的是，无论是客户端还是 API 提供端，在开发之前都需要先定义一组公共的 API 接口，写成文档，然后才能进行编码。如果服务端和客户端是共同开发的话，那么服务端通常会先实现能返回固定字符串的 API 接口，在以后的开发中再慢慢去实现 API 的功能。
5、技术的创新，Docker 正在快速发展，工具也在不断更新，没有人能预见到未来 Docker 会是什么样子的。你在复杂的系统中 Docker 使用的越多，越是可能会发现技术上的空白和未来技术发展的方向。
前一篇 基于docker部署的微服务架构（一）：服务注册中心 已经成功创建了一个服务注册中心，现在我们创建一个简单的微服务，让这个服务在服务注册中心注册。然后再创建一个调用者，调用此前创建的微服务。
新建一个maven工程，修改pom.xml引入 spring cloud 依赖:
在 resources 目录中创建 application.yml 配置文件，在配置文件内容:
这里eureka的注册地址为上一篇中设置的defaultZone。
在 java 目录中创建一个包 demo ，在包中创建启动入口 AddServiceApplication.java
在demo包下新建一个子包controller，在controller子包下创建一个controller对外提供接口。
在服务注册中心已经运行的情况下，运行 AddServiceApplication.java 中的 main 方法，启动微服务。
访问服务注册中心页面 http://localhost:8000 ， 可以看到已经成功注册了 ADD-SERVICE-DEMO 服务。
启动第二个实例，修改端口为 8101 ，修改 AddController.java 中的输出信息为
再次运行 AddServiceApplication.java 中的 main 方法。
访问服务注册中心页面 http://localhost:8000 ， 可以看到已经成功注册了两个 ADD-SERVICE-DEMO 服务，端口分别为 8100 和 8101 。
新建一个maven工程，修改pom.xml引入 spring cloud 依赖:
在 resources 目录中创建 application.yml 配置文件，在配置文件内容:
在 java 目录中创建一个包 demo ，在包中创建启动入口 RibbonClientApplication.java
这里配置了一个可以从服务注册中心读取服务列表，并且实现了负载均衡的 restTemplate 。
在demo包下新建一个子包controller，在controller子包下创建一个controller对外提供接口。
可以看到这里的请求url用了服务注册中心对应的 Application 。
运行 RibbonClientApplication.java 中的 main 方法，启动项目。
在浏览器中访问 http://localhost:8200/add?a=1&b=2 ，得到返回结果：
多次访问，查看 AddServiceApplication 的控制台，可以看到两个 ADD-SERVICE-DEMO 被负载均衡的调用。
demo源码 spring-cloud-1.0/ribbon-client-demo
新建一个maven工程，修改pom.xml引入 spring cloud 依赖:
在 resources 目录中创建 application.yml 配置文件，在配置文件内容:
在 java 目录中创建一个包 demo ，在包中创建启动入口 FeignClientApplication.java
在demo包下新建一个子包service，在service子包下创建一个接口 AddService.java 调用之前创建的微服务 ADD-SERVICE-DEMO 。
这里 @FeignClient 注解中的参数为服务注册中心对应的 Application 。
在demo包下再新建一个子包controller，在controller子包下创建一个 FeignController.java 对外提供接口。
FeignController 里注入了刚才创建的 AddService 接口。
运行 FeignClientApplication.java 中的 main 方法，启动项目。
在浏览器中访问 http://localhost:8300/add?a=1&b=2 ，得到返回结果：
多次访问，查看 AddServiceApplication 的控制台，可以看到两个 ADD-SERVICE-DEMO 被负载均衡的调用。
demo源码 spring-cloud-1.0/feign-client-demo
以 add-service-demo 为例，
复制 application.yml ，重命名为 application-docker.yml ，修改 defaultZone 为：
这里修改了 defaultZone 的访问url，如何修改取决于部署docker容器时的 --link 参数， --link 可以让两个容器之间互相通信。
修改 application.yml 中的 spring 节点为：
这里增加了 profiles 的配置，在maven打包时选择不同的profile，加载不同的配置文件。
在pom.xml文件中增加：
选择 docker profile，运行 mvn install -P docker ，打包项目并生成docker镜像， 注意docker-maven-plugin中的 <entryPoint> 标签里的内容不能换行，否则在生成docker镜像的时候会报错 。
运行成功后，登录docker节点，运行 docker images 应该可以看到刚才打包生成的镜像了。
在前一篇中，已经创建了一个 service-registry-demo 的docker镜像，这里先把这个镜像运行起来。
对这条命令做个简单说明， -d 指定当前容器运行在后台， --name 指定容器名称， --publish 指定端口映射到宿主机， --volume 这个挂载是为了解决容器内的时区和宿主机不一致的问题，让容器使用宿主机设置的时区，最后指定使用的docker镜像，镜像名称和标签需要根据自己的情况做修改。
运行这条命令之后， service-registry-demo 的容器就启动了。访问 http://宿主机IP:8000 ，打开注册中心的页面。
下边启动 add-service-demo 容器，
这条命令和上一条差不多，只是增加了一个 --link 参数， --link 指定容器间的连接，命令格式 --link 容器名:别名 ，这里连接了之前创建的名为 service-registry-demo 的容器，这里的别名和 application-docker.yml 文件中配置的 defaultZone 一致。其实就是通过别名找到了对应的容器IP，进到容器里查看 hosts 文件就明白了，其实就是加了条hosts映射。
add-service-demo 容器启动成功之后，刷新配置中心的页面，发现已经注册到配置中心了。
刚开始进入软件行业时还是单体应用的时代，前后端分离的概念都还没普及，开发的时候需要花大量的时间在“强大”的JSP上面，那时候SOA已经算是新技术了。现在，微服务已经大行其道，有哪个互联网产品不说自己是微服务架构呢？
但是，对于微服务的理解每个人都不太一样，这篇文章主要是聊一聊我对微服务的理解以及如何搭建经典的微服务架构，目的是梳理一下自己的一些想法，如果存在不同看法的欢迎指正！
首先，什么是微服务呢？
相对的，要理解什么是微服务，那么可以先理解什么是单体应用，在没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一起，那时候的一个B/S应用架构往往是这样的：
但是，当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡，架构就变成这样了：
后面发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体相应，单体应用的架构就变成：
上面3中架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本的缺点：
我认为任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。
在微服务架构之前还有一个概念：SOA（Service-Oriented Architecture）-面向服务的体系架构。我认为的SOA只是一个架构模型的方法论，并不是一个明确而严谨的架构标准，只是后面很多人将SOA与The Open Group的SOA参考模型等同了，认为严格按照TOG-SOA标准的才算真正的SOA架构。SOA就已经提出的面向服务的架构思想，所以微服务应该算是SOA的一种演进吧。
撇开架构先不说，什么样的服务才算微服务呢？
微服务架构，核心是为了解决应用微服务化之后的服务治理问题。
应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件： 服务注册中心 ，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：
解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件： 配置中心 ，微服务架构就变成下面这样了：
以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：
上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：
目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那两年的停更严重打击了开发人员对它的信心，Spring Cloud已经逐渐成为主流，比较两个框架的优劣势的文章在网上有很多，这里就不重复了，选择什么框架还是按业务需求来吧，业务框架决定技术框架。
Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：
本章节主要介绍如何基于Spring Cloud相关组件搭建一个典型的微服务架构。
首先，创建一个Maven父项目 spring-cloud-examples ，用于管理项目依赖包版本。由于Spring Cloud组件很多，为保证不同组件之间的兼容性，一般通过 spring-cloud-dependencies 统一管理Spring Cloud组件版本，而非每个组件单独引入。
pom.xml配置如下：
参考上面业务服务A搭建另外一个业务服务B。
目前网上很多说是下一代微服务架构就是Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大厂加持所以呼声更高。Service Mesh我接触还不多，但是个人感觉并不一定能称为下一代微服务架构，可能认为是服务治理的另外一种解决方案更合适，是否能够取代当前的微服务架构还需要持续观察。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）