微服务与 Docker 是什么关系？

因公司业务市场的发展与技术架构等结合因素，希望接下来的产品架构能支撑轻量级、高并发、大数据、智能化、易维护、动态扩展等方向发展，这段时间参与我们公司架构研发部等一起负责架构研发等相关工作，从中开始学习微服务、docker、非功能设计相关技术，公司使用Spring Boot、Spring Cloud、Docker和Netflix、Kubernetes、Prometheus等开源工具来构建与监控微服务。

在团队中我主要负责工作内容是CaaS平台&devops建设，目前主要负责框架的性能诊断分析优化工作，后期主要工作内容：主机环境搭建管理、环境标准化、微服务跨主机通信支持、微服务动态扩容和缩容、微服务可用性监控、自动化部署运维规范、微服务基础镜像设计、性能测试与调优等非功能性技术工作。

虽然才开始介入事件，但是也从公司的资深架构专家和他团队人员介绍，慢慢了解微服务与docker等关系和如何实施工作。一个优秀的架构领导在团队管理上，对技术的开发性、共享性、持续更新、容纳百川等魅力体现，这段时间让我深有感悟，也让我能最短时间学习到新技术，并感受到持续学习的必要性。在此分享一些学习笔记，与大家交流。

微服务与传统服务区别

传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问WEB界面。其业务逻辑定义业务流程、业务规则以及各领域实体。而其适配器包括数据库访问组件、消息组件以及访问接口等，类似打车软件、叫餐软件。尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用居多。例如Java应用程序会被打包成WAR，部署在Tomcat之间存在优缺点，但是随着市场的发展，用户数、数据量、业务模式的增长，传统模式存在一些缺点：

1、部署不灵活：构建时间长，任何小修改必须重新构建整个项目；

2、稳定性不高：一个对象内存释放不及时等问题，可能会导致整个应用挂掉；

3、扩展性不够：高并发情况下的业务需求，在扩展性方面比较麻烦；

所以，现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务，每个业务逻辑都被分解为一个微服务，微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

微服务优点，比传统的应用程序更有效地利用计算资源。这是因为它们通过扩展组件来处理功能瓶颈问题。

• 一种软件架构模式

• 复杂应用解耦为小而众的服务

• 各服务精而专

• 服务间通信通过API完成

• 更快且更容易更新

而为了满足如上几大优点或者说规则微服务细化带来工作维护麻烦性等，一般使用docker技术结合来提供微服务的优势和运维工作的高效性。

微服务与docker关系

Docker 是一个开源应用容器（当然目前也分为CE和EE版本，不完全开源化，也存在收费版本），让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

Docker 作为容器工具可以把：业务逻辑容器、数据库容器、储存容器、队列容器使得软件可以拆分成若干个标准化容器，然后像搭积木一样组合起来，让彼此通信，从而形成微服务。

因此微服务很适合用 Docker 容器实现，每个容器承载一个服务。一台计算机同时运行多个容器，从而就能很轻松地模拟出复杂的微服务架构。

▲容器、物理机、虚拟机之间的关系

备注：测试微服务应用程序也更复杂。服务类似的测试类将需要启动该服务及其所依赖的任何服务，服务之间的通信接口技术性测试要求多一些，而且在非功能测试技术要求工艺更加复杂，软硬件的配置合理性、有效性、资源利用的充分性等监控要求更高。