浅谈容器、微服务和互联网架构
随着云服务的兴起，企业应用正在从分层式架构逐步迁移到互联网架构。传统的企业应用架构通常是单一架构（Monolithic），即典型的MVC三层架构。以一个主流的J2EE企业应用而言，其按照模型（数据层）——控制器（服务层）——视图（访问层）进行构建，然后打包为一个war包，部署运行于J2EE应用服务器上，例如Tomcat、JBoss、WebLogic等。
然而，经过多年应用，Monolithic架构也逐渐老化，越来越不适应技术的发展。首先，随着加入的应用功能增多，产生了代码堆积现象，系统越来越庞大和复杂。尤其是引入敏捷开发后，产生了较多问题。例如应用持续集成方法时，自动加载、编译、加载、测试整个应用代码的时间过长，不能快速形成正反馈。其次，组件与组件之间的耦合性太强，所有应用都运行在服务器上的相同进程中。应用规模增大后，只有同时增加应用的副本，将多个副本部署到多个服务器上，无法实现弹性伸缩。最后，开发团队之间，工作交集复杂，协调耗散大。 从长期实践看，Monolithic架构天然的不具备健壮性，因为一旦某个组件出现问题，整个服务基本上就挂了。自身不具备分布式服务能力，通常需要依赖于负载均衡器、数据库HA等来实现服务的分布化和负载分担。相对而言，互联网架构优势在于分布式、去中心化，支持弹性伸缩。其核心是轻应用、微服务。微服务架构也是从Monolithic架构演进来的。Monolithic应用中按照职责的不同，拆分解耦成一个个的单独微服务（Micro Services），每个微服务都对应了一个独立的业务功能，也只定义了该功必须的一些操作。从下图可以形象的说明。
微服务独自或者共同部署在多台应用服务器上，微服务之间通过标准的Restful接口实现访问。这样当一个微服务出现问题时，并不会影响到其他的服务。而且，微服务可以基于资源的需求进行独立扩展，可以被部署在更小的主机上。各个微服务使用的开发语言也可以不同，只要保持接口协议统一。 随着移动互联网的爆发，越来越多的采用前端手机APP（Native或HTML5）+后端应用（Java、NodeJS等）的开发/部署模式，两者之间通常采用Restful方式实现通讯，天然的实现了前台和后台的解耦，这也为微服务的流行提供了根本动力。 然而，不容忽视的是，微服务同样存在一些劣势。因为微服务通常部署在多个主机上，所以大量微服务的管理也成为一个难题。如果微服务使用不同的编程语言将开发，这就意味着每个服务的部署都需要完全不同的库和框架，从而服务的部署会非常复杂。 幸运的是，Linux容器技术的使用可以很大程度上缓解微服务架构所带来的问题。Linux容器技术使用了类似cnames和namespaces这样的内核接口，它允许不同容器共享相同的内核，同时容器之间还进行了完全的隔离。 目前流行的Linux容器主要有Docker和Rocket。以Docker为例，Docker执行环境使用了一个被称为libcontainer的模块，它标准化了这些接口。Docker同样为容器镜像提供了一个类GitHub的资源库DockerHub，让容器的共享和发布非常简单，也正是这种相同主机上的容器隔离简易了不同语言开发的微服务代码部署。使用Docker，我们可以创建一个DockerFile来描述所有用到的语言、框架和服务间库的依赖性。
将微服务应用放置在容器中，带来了快速与可移植性。从开发、测试、上线，实现了“一次编写，到处运行”。
总之，通过容器、微服务的有效结合应用，最终帮助企业应用演进到互联网架构，实现IT投资和收益的最优化。