业务容器化改造（二）

上一篇介绍了传统业务部署时面临的问题，这些问题会导致业务无法进行高速迭代，满足不了互联网环境下业务的持续集成、持续交付、持续部署的要求，需要对业务进行容器化的改造。
那么，我们应该如何对传统业务进行容器化改造呢？我认为应该从以下三个方面入手。

一、应用拆分

传统业务的特点，功能模块划分不清晰、结构臃肿、代码耦合度高。对传统业务进行容器化改造，需要将业务进行变革。
1.对功能模块进行拆分
对原有系统的复杂模块进行拆分，尽量使每个模块具有单一功能。功能拆分不是为了拆分而拆分，其主要目的是可以对拆分后的服务进行水平扩展以解决传统的单体应用在业务急剧增加时所遇到的问题，而且由于拆分的服务系统中专业的人做专业的事，人员和项目的职责单一、低耦合、高内聚，产生问题的概率就会降到最低。
2.使用统一接口通信
拆分后的模块化组件，需要通过定义明确的接口或者契约联系起来，通常是通过网络协议来完成的，可以使底层的TCP/IP,也可是应用层的HTTP,也可以是消息队列协，甚至可以是约定的某种数据库存储形式，这使各种模块化组件可以以一种统一和通用的方式进行交互。在微服务架构中，通常使用RESTful风格的API和轻量级的消息通信协议来完成。
3.无状态化设计
阻碍单体架构变为分布式架构的关键点就在于状态的处理。如果状态全部保存在本地，无论是本地的内存，还是本地的硬盘，都会给架构的横向扩展带来瓶颈。所以要将整个架构分成两个部分，无状态部分和有状态部分，而业务逻辑的部分往往作为无状态的部分，而将状态保存在有状态的中间件中，如缓存、数据库、消息队列等。这样无状态的部分可以很容易的横向扩展，而后端的中间件是有状态的，这些中间件设计之初，就考虑了扩容的时候，状态的迁移，复制，同步等机制，不用业务层关心。

二.构建DevOps体系

传统应用变为分布式架构后，传统手工部署方式war包或者jar包的方式满足不了持续集成、持续交付的要求。传统业务的转变可以从DevOps的体系建设为入口，打造敏捷开发和精益运维体系。DevOps 中的 Dev 指的 Development，Ops 指的是的 Operations，DevOps 就是打通开发运维的壁垒，实现开发运维一体化，让开发和运维相互之间的沟通更加顺畅、迅捷，从而使企业更能适应市场的变化。
通过DevOps工具进行CI/CD流水线的编排，以自动化部署方式代替手工部署方式，以统一标准化的容器镜像为交付物，使得自动化软件开发和 IT 团队之间可以更快、更可靠地构建、测试和发布软件。
同时，DevOps转型需要一个过程，工具虽然能帮助我们有效的运用DevOps持续交付。但是它并不是DevOps的全部。它需要建立一种文化，通过人、过程和工具的紧密结合，共同协作并且逐渐形成。不能把持续交付理理解成团队里的某个人的工作，而是需要从各个方面收集反馈信息，持续的监控并优化过程，按照不断改进的过程来实现理想的交付状态。

三. 搭建容器平台

当我们在DevOps过程中使用Docker进行容器管理时，Docker 只是满足在单个主机上管理容器的需求，面对部署在多个主机上的容器时就无所适从了。为了超越单个容器管理，我们必须转向编排工具。容器编排工具将生命周期管理能力扩展到部署在大量机器集群上部署的复杂的、多容器工作负载。
以容器编排工具有基础，结合私有镜像仓库、容器日志的收集和分析、应用apm监控等，构建功能完备一体化的容器平台，使企业具备容器编排、容器生命周期管理、资源调度、弹性伸缩、应用监控的能力，可以进一步提升企业业务容器化的能力。