01.对容器化的需求

在系统上线之前，我们往往需要部署多套环境用于不同需求的验证：开发--->测试--->准生产（按客户部署）。企业内部的资源随着产品的推进远远不够，并且多套环境怎么集中管理已成为问题。从20215年企，我们的产品推广了几十家规模企业，并且在不断的让我们进行优化/升级等。内部环境如果同时部署，基于多版本管理需求，这是我们无法接受的，而最终成为了内部没有环境，需要依赖业主单位的环境，在需要的时候把测试环境拿回来重新做......

对我来说不太好接受，业主单位的信息原则上只进不出........

近期来自内部积累问题/企业需求趋势等，我们在不断试探容器化/云化部署方案。我们自身的产品也不断在微应用化构建。

面向未来的实现应该是面向容器化部署/面向云化部署/基于微应用化高并发高可用支持。

1.什么是容器？

当前最流行的容器应该是docker,容器是虚拟化改造后相对独立的运行环境，也可用说就是一台虚拟出来的虚拟机，只是比较轻量化，但可用不断补充需要的组件，最终实现应用最小运行环境。最终实现在一台硬件服务器上可用根据需要创建多个容器实例，实现对外服务。

2.什么是云化部署？

当我们在所有的硬件资源中装入容器管理管理服务，并安装好容器编排应用后，所有的硬件资源将虚拟成一个较大的云环境，我们不再需要了解应用运行在哪个具体的硬件上，而是由容器编排服务根据资源需要在被管理的所有硬件资源中查找合适的应用资源，然后调度容器服务创建运行容器，最终通过统一的出口提供服务。

3.什么是微应用化改造？

当应用程序的功能达到一定的规模后，基于产品长期运营需求与服务并发需求。需要对应用进行拆解，最终形成相对自洽的服务群。服务群之间基于API进行相互集成调用，最终实现具体的业务。在产品运行过程中，可用基于并发压力不断平行扩展微应用服务，最终使用合理的资源解决高并发、高可用需求。

微应用是微服务的一个更聚集的服务环境，但同样需要考虑服务治理体系的支持。应用注册与发现，统一配置中心，远程调度集成，服务熔断与降级，统一服务网关,调用链追踪等微服务管理体系。

从整体来看，容器化部署，云服务编排等主要面向硬件资源管理。微应用化是在云化部署的基础上实现多容器，动态扩容等基础上构建的应用。解决当下高并发/高可用等现实需求。