简单谈下对Docker容器平台和微服务架构（1.19）
注：图片为HP的一个PaaS平台参考架构（K8S+Docker轻量模式）
在原来博客上大量谈私有云PaaS平台整体架构设计的文章可以看到，说的比较多的是：
1. 对于PaaS平台采用类似CloudFoundry或Cloudify的开源PaaS平台解决方案
2. 对于业务系统应用架构设计应该实现组件化和模块化，每个组件为最小可独立管理单元
在转移到当前主流的轻量架构下，整体架构思路没有太大的变化，仍然是强调组件化和服务化，同时强调服务和资源的整体管理能力。只是对于PaaS层采用更加轻量的Docker容器，组件化架构转变为微服务架构。
Docker本身仅仅是比虚拟机更加轻量的但是又可以实现资源隔离的容器，由于是在操作系统之上，更多的时候我们会强Docker容器放到PaaS层来谈。但是Docker本身仅仅是容器，是资源调度的单位，在当前开源解决方案中用的比较多的是通过Kubernetes实现容器集群管理和资源调度能力。
因此理解为Kubernetes+Docker构成了基础的PaaS层能力。Kubernete实现了容器集群管理和调度，更加准确来说应该是实现了容器这种更小资源的全生命周期管理能力。
在Docker容器中部署的是业务组件，比如WAR包，而组件本身可以暴露服务接口，而这些暴露的服务接口本身又需要一个统一的地方进行服务的集中管理。即这块能力主要是由微服务架构中的微服务网关来实现，服务网关需要实现服务的注册，接入，开通，运行监控，日志，限流等诸多基础能力。
Kubernetes是实现容器这种资源的全生命周期管理
这个理解清楚后，那么原来理解的一些内容存在错误，即实际在微服务架构中，对于微服务模块动态扩展后新的微服务模块本身的负载是通过 Kubernetes层来完成的，因为这本身是属于同一个资源不同副本之间的资源池负载均衡。而对于微服务网关而言本身不应该承担这一层的负载和路由映射。
即在和Docker容器和Kubernetes容器集群管理结合后，原来在微服务网关层的微服务模块动态调度注册增加等能力应该转到Kubernetes组件来完成。即对于一个微服务模块而言，只应该在微服务网关注册Kubernetes集群管理暴露出来的虚拟IP和端口信息。
简单点来说就是如果是全新模块加入则涉及到在Kubernetes和微服务网关都需要注册。而如果是老的微服务模块引起了容器资源动态调度和扩展，则只需要在Kubernetes层完成接口。
原文 http://blog.sina.com.cn/s/blog_493a84550102woq1.html正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
