众所周知，基于微服务的应用更适合在容器上运行，可以最大限度发挥微服务的优势。但在将微服务应用于容器的过程中，由于用户实际情况和开发计划的差异，所采用的路径和方案也有所不同。如何选择最合适的方案，有哪些顾虑，如何处理，都是需要认真考虑的。
今天，我们将与您讨论这个主题“当我们谈论微服务被容器化时，我们在谈论什么？”分享的内容主要包括微服务应用容器化的几种典型场景，需要注意的问题以及相应的解决方案。
本文为6月30日《CloudTech博云说》第五期。“当我们谈论容器上的微服务时，我们在谈论什么？审查和整理”。
01微服务和容器:1+1>2
大家一定听说过云原生或PaaS落地的三驾马车，即微服务、容器和DevOps。三者相辅相成，有着广泛的联系。在云原生技术落地过程中，对应用敏捷迭代和健壮运行的需求是推动微服务应用产生和发展的重要因素。虚拟机作为IT基础设施的支撑，从单一应用到微服务应用，已经无法满足微服务应用部署的核心要求，即高性能、高可用性、高灵活性的保障。容器技术的兴起不是偶然的，只是满足了微服务应用时代的需求。
云原生技术社区最受认可的思想家之一阿德里安·科克罗夫特曾表示，微服务架构的优势在与容器结合后得到了进一步放大。原因是微服务鼓励软件开发者将整个软件解耦成更小的功能段，这些功能段可以应对外部故障。容器进一步扩展了这种分离，可以将软件从底层硬件中分离出来。
ICT研究院《中国云原生用户调查报告》显示，中国有64%的用户将容器技术应用于微服务应用的部署，这也是国内使用频率最高的场景。
02微服务的发展过程
在说微服务的容器化部署之前，我们先来看看微服务的发展过程。虽然微服务架构的类型很多，但总体来说，微服务架构有两种:一种是具有一定入侵性的传统微服务架构，如Spring Cloud、Dubbo、gRPC等。，另一类是无创微服务架构ServiceMesh，如Istio、linkerd、Sofamosn等。，这是近年来兴起的。
其实从微服务的发展演变来看，除了所谓的入侵与非入侵的区别，微服务的另一个趋势是向容器靠拢。传统的微服务架构并没有考虑太多的容器化部署，ServiceMesh天生就与kubernetes紧密结合。不得不说，这也是一个明显的需求主导的技术变革趋势。
03集装箱上的微服务，需要注意什么？
当然，从虚拟机部署到容器化部署，微服务肯定会带来很多改变。那么主要的变化是什么呢？我们从以下五个主要角度做了一些简单的总结。
部署形式:从虚拟机到容器的变化；
通信方式:部署在容器上需要增加一个容器网络层；
服务框架:服务框架中会更多考虑服务网格方案，这将导致传统微服务框架和服务网格的共存和演进；
管理架构:容器化服务/集群与非容器化服务共存，需要容器化服务+非容器化服务的统一部署和运维管理场景。
应用程序架构:需要对服务进行进一步的云原生/无状态转换。
基于这些变化，我们可能会有一些疑惑和不确定性。比如，如果是某个框架开发或购买的某个厂商的微服务应用，可以装入容器吗？你能把容器放上吗？会不会很麻烦？有哪些问题？是注册了nacos，还是使用了某某组件和中间件，影响了容器？带着这些问题，我们先来看看一个典型的微服务架构应用。
该图是一个典型的微服务架构应用。从业务维度看，由前端和后端服务组成，基于传统的管理框架提供注册和配置。从组件来看，包括前端、后端服务、注册表、配置中心、网关和中间件。对于微服务的管理，有服务调用、负载均衡、限流和融合、服务监控、事务跟踪、分布式消息等。Dubbo或SpringCloud可以提供这些管理组件的统一集成方案。基于以上，此时我们将初步形成两种微服务应用容器化方案:
第一，各种组件，前端和后端应用容器化，改变部署形式。此时，业务和治理逻辑还没有完全解耦，治理和监控仍然对业务代码有一些侵入。
第二，框架也在进化，采用服务网格的ServiceMesh方案，然后容器化。
在第一种场景中，我们可能更关心这些组件和服务的容器化转换的顺序，而在第二种场景中，会出现ServiceMesh方案的选择，以及传统的微服务治理框架如何更方便地演进到ServiceMesh框架等问题。针对这些问题，我们也梳理了几个典型场景。
总的来说，有三种典型的情况:
传统的微服务架构应用上层容器场景，包括部分上层容器和所有上层容器。
网格应用上的容器场景涉及到应用直接采用ServiceMesh框架和传统的微服务框架来移植或兼容ServiceMesh。
微服务应用容器化后统一管理、运维的场景。
下面我们来看看在不同场景下需要注意什么。首先，有两种方法可以将容器应用于微服务。在应用容器化的场景中，将关注应用状态维护、配置、通信、日志、版本发布和部署等。在应用容器化的场景下，我们需要注意网络互操作性和正确的配置。由于时间关系，这里就不一一展开了。请参考我们最近出版的应用容器指南。
下面我们来阐述一些重点。
04微服务在容器上，中间件不在容器上。如何解决网络问题？
首先，在应用容器化，也就是微服务应用容器化，中间件不容器化的场景下，有一个痛点或者关注点，就是如何高效安全的在容器集群内外互相通信，就像以前使用虚拟机网络一样。
这张图片很好地展示了这一场景。一些服务部署在kubernetes容器集群上，但是注册表、数据库中间件等。仍然部署在虚拟机或物理机上，甚至一些服务运行在容器集群之外。
然后对于注册中心来说，希望所有服务都像之前的虚拟机部署一样注册，网络直通，服务对数据库中间件的访问性能不会降低。事实上，这对集装箱集群的网络方案提出了更高的要求。
目前业内有两种集装箱网络方案，即Underlay和Overlay模式。这两个模型很好理解。一种是容器网络使用虚拟机网络的扁平化组网方案，是Underlay，另一种是容器网络在虚拟机网络之上搭建一个私有网络，是Overlay。
对于这种内外贯通场景的容器集群，推荐使用Underlay方案，因为该方案提供了更高的网络性能和更低的性能损失，并且利用原有的虚拟机网络实现二层互通，可以基于固定的IP地址配置准确完整的防火墙策略。
如果选择覆盖网方案，需要通过nodeport或Ingress等特殊配置实现内外网互联。叠加网方案甚至推荐微服务和中间件全部容器化的场景，跨集群通信可以通过网络联邦实现高性能互联。
05微服务和中间件都是容器化的。如何解决中间件的容器化？
就像我刚才说的，在微服务和中间件都容器化的场景下，除了网络选择，还有一个关键的关注点，就是中间件的容器化。比如MySQL，Redis，Kafka，Nacos等等。这些中间件不仅需要考虑如何在容器中部署，还需要构建包括生命周期管理、可观测性、灾难恢复、自动运维以及无缝升级在内的中间件管理能力。
它不仅保证了容器化中间件的高性能和可靠性，而且实现了更高的自动化操作和维护能力。在这一领域，业界有一个基本的共识方案，即采用运营商自动部署和安排中间件的单实例/高可用模式，并提供相关的全生命周期、监控运维、备份恢复能力。
与传统的中间件管理和运营方案(如基于ansible的方案)相比，中间件通过Operator的容器化，或基于云的生化，具有一些独特的优势。一是可以充分发挥容器的高性能和灵活性，同时具有更强的自动化运维能力和快速部署能力。现在社区里有很多中间件的开源运营商，但是如果要实现真正的企业级落地，还需要做很多的增强。
比如多版本、个性化指标、大规模数据迁移、高性能通信、网络的安全可靠、维护和故障排除的高效率。存储还要求高性能、低消耗、就地重启、智能排列、运维简单等。同时，开源运营商也缺乏跨数据中心的容灾和备份能力。因此，在实际实施中，需要考虑这些问题，根据运营商自身的使用场景和需求，合理选择运营商，是否做相关增强。
06传统微服务如何向ServiceMesh演进？
在微服务应用使用ServiceMesh框架的场景下，有一个问题是大多数用户绕不开的，那就是现有的传统微服务框架如何向ServiceMesh框架演进？我们可以反过来想。有必要先这样吗？或者为什么要这么做？
这时候我们首先要知道，在传统微服务框架下很难解决的一大堆痛点是什么？
业务代码与微服务框架SDK强耦合；
服务升级和微服务框架升级的强绑定，使得微服务框架的演进困难重重。
微服务框架SDK多语言并行开发维护成本高，原因是少数语言进步快，少数语言进步慢；
异构服务框架难以共存并完成渐进演进，导致微服务应用从单一应用转型的启动成本高；
单一的语言限制了应用场景和人才的多样性。比如Springcloud主要支持Java，但对多种语言的支持较差。
采用ServiceMesh框架，实现了业务逻辑和治理功能的分离。在服务网格中，在治理能力下沉到基础设施之后，业务的开发、部署和升级与服务治理的基础设施解耦。业务开发人员可以专注于自己的业务部分，只要不修改业务代码，不需要重新编译，不需要在线修改。当治理能力的升级只需要基础设施的升级时，基础设施的升级对用户业务完全没有影响。我们可以看到，ServiceMesh方案有很多明显的优势，比如多语言多协议支持，无入侵，解耦下沉，开发更规范，难度更低。
这时候你可能会有一个疑问，把传统微服务架构的应用迁移到ServiceMesh上麻烦吗？
在相关的项目实践和落地中，我们总结了两种常见的改造方案，其共同的核心是做解耦、剥离和切割。首先流量管理的相关工作要通过特使等Sidecar来完成，另外要考虑的是业务代码本身是否移动。
更好的理解是裁掉服务治理SDK；另一种保守的方式是只修改配置，保留SDK，但实际保留的主要是代码框架、应用协议等开发功能，与微服务治理相关的内容全部卸载到基础设施上。这就需要原有的注册中心，治理等相关功能要用kubernetes和ServiceMesh来完成，包括注册中心使用kubernetes服务能力，直接使用Kubernetes服务名和端口访问目标服务，并根据自身需求逐步用网格中的治理能力来替代原有的相关能力。
修改方法需要手动配置ribbon，该机制用于在相应微服务的后端实例地址中配置Kubernetes服务名称和服务的端口。当在Spring cloud框架中仍然访问原始服务器微服务名称时，请求将被转发到kubernetes的服务和端口。这样，访问将被网格数据表面拦截，因此访问将到达网格数据表面。发现服务负载均衡和各种流量规则可以应用到网格中的能力，也就是说原来SDK中的内容还在，治理组件还在，只是被绕过了。这样就可以在不重新编译的情况下修改代码0，实现真正的非侵入式代码的转换和移植。
不过SDK的切割方式改革的更彻底。从最终的图像尺寸来看，整个项目的体积也可以大大缩小。就这样，客户根据实际使用情况进行各种删减，大部分最终将春云贬为Spring Boot。这个方法会有一定的代码修改工作，需要重新编译。
这两种方案可以根据业务发展的现状、规模和需求进行选择。
说到微服务的管理和运营，我们会讲究“两个统一”。一个是微服务框架的统一管理，一个是容器和非容器部署架构的统一管理。我们的实际情况可能是，有些应用是Springcloud框架，有些是Dubbo框架，有些是ServiceMesh框架，这些应用可能一部分部署在虚拟机上，一部分部署在容器上。还是要建立一个全面、完整、统一的发布和运维管理体系。否则会出现多套管理平台，增加运维工作量，降低运维效率。
这是一个典型的建议。我们建议微服务的运维管理要有异构的支持，包括监控和治理。我们可以在服务监控上做统一设计，服务治理在创建应用时可以选择不同的架构来选择不同的治理方案，然后根据平台的统一治理组件管理能力或者Sidecar能力来支持不同的治理能力。
07关于博云
最后，简单介绍一下博云针对我们今天讨论的场景，在产品和解决方案方面做了哪些工作。
对于企业微服务的转型，博云可以提供微服务咨询服务，拥有相关的企业级产品微服务应用管理平台BMS，涵盖开发、发布、运营阶段。同时提供中间件统一管理、企业级API网关等组件，拥有在大量客户尤其是金融客户方面经验丰富的服务团队，能够提供一整套产品和服务解决方案。
在产品设计上，以应用为核心，从开发和发布的角度提供统一的双模应用发布、管理、运维监控，从运营的角度提供多框架统一治理，真正实现同书同车。
博云的中间件管理平台BMM针对中间件管理场景，基于开源运营商做了大量的企业级增强，针对前面提到的开源运营商的一些不足，比如对高性能网络和存储的要求，跨机房容灾备份的要求，做了全面的设计改进。目前已支持MySQL、Redis、Elasticsearch、Kafka、RocketMQ、PostgreSQL、Nacos、Zookeeper等主流中间件的全生命周期管理能力。在很多项目的实践中，提高了中间件交付效率，降低了运维成本，节约了资源成本。
在讨论容器网络的两种网络模型之前，博云开发的产品BeyondFabric可以提供完整的解决方案支持。它结合了大量的实践场景，从功能完整性、高性能、稳定可靠、易用性等维度进行了全面的设计。其中，Fabric Underlay方案提供了pod和工作负载的固定IP地址和地址段、pod的多数据平面管理、多网卡和多协议支持，通过DPDK和动态qos提供高性能和低时延支持，支持IPAM地址池管理场景下的大规模IP快速分配。
Fabric Overlay方案提供网络联邦，在同构联邦场景下提供高性能互通方案，不使用网关。此外，它提供多种隧道协议和隧道加密支持，并能提供分布式出口网关。eip可以在名称空间和工作负载级别设置。还有一些其他的核心能力，比如微分段解决大规模集群流表的性能问题，分布式控制器保证网络稳定可靠运行，支持windows网络支持arm架构集群，这里就不赘述了。我们微信官方账号里也有集装箱网的文章。感兴趣的朋友可以搜一下看看。
今天的分享到此结束。谢谢你。
