容器与微服务

当前在讨论容器和云原生应用话题时，微服务也成为一个热门的讨论点。在很多人看来微服务和容器是密不可分的。

微服务概述

微服务（microservice）的核心理念是将大的单体应用（monolithic application）拆散，形成多个相对较小的单体应用。这些单体应用可以独立进行开发、测试和部署，通过对这些单体应用的编排和组合最终提供完整的服务。微服务将传统的应用架构化整为零，目的是提高应用开发和交付的效率。在传统的单体应用时代，虽然有模块的概念，但是在构建时，众多的模块往往会被构建成一个单一的、庞大的部署包。单体应用的更新往往会导致整个系统的所有服务中断。而在微服务的场景中，所有的功能都是由一个或多个服务提供的，当某个微服务进行更新和维护时，只会影响该服务涉及到的业务，其他模块可以正常对外提供服务。微服务之间相对独立，它们各自可以有各自的开发周期，相互之间不会有过强的捆绑关系，这样有助于加快系统整体迭代更新的节奏。从团队组织上来说，微服务的划分颗粒度较细，可以形成更有针对性的权责关系。

微服务与容器

目前常见的一种错误认识是”要使用微服务架构就要使用容器”，或者”使用容器就必须实现微服务架构“。其实微服务和容器之间并没有很强的捆绑关系。微服务和具体的语言和技术也没有直接的绑定关系。要实现微服务，不一定要使用容器，但是容器和微服务是天生一对。应用的微服务化，除了技术层面，还需要从开发运营团队的文化，组织架构着手。从技术层面看，容器具备在大规模云环境中快速部署复杂应用的能力，十分适合应用在微服务架构的场景中使用容器。反过来看，容器在未来成为云上主流应用运行环境后，传统的大型单体应用运行在容器中并不是一个很好的选择。未来的应用架构必须做出调整，让未来的应用更适合在容器内运行，在云上运行，甚至最终变成云原生应用（cloud native application）。微服务和容器是两个相辅相成的概念，它们的最终目的都是一致的，那就是提高应用开发、测试和部署的效率，让IT变得更敏捷。

关于微服务的细节这里不再展开，推荐参考 http://www.csharpkit.com/microservice.html 。