家喻户晓，基于微服务的利用更加适宜运行在容器上，能够最大化施展微服务的劣势。但在微服务利用上容器的过程中，因为用户理论状况和倒退布局的差别，采取的门路和计划也有不同。如何抉择最合适的计划，其中的关注点有哪些，并如何应答，都须要去认真思考。
明天咱们跟大家一起聊一聊这个主题《当咱们说微服务上容器，咱们在说什么》，分享的内容次要包含微服务利用容器化的几个典型场景、须要关注的问题以及对应的解决方案。
本文是 6 月 30 日“CloudTech 博云说”第五期分享内容《当咱们说微服务上容器时，咱们在说什么？》的回顾整顿。扫描上方海报二维码或点击文章开端的浏览原文，回看精彩视频！
01 微服务与容器：1+1>2
大家必定都据说过云原生或者 PaaS 落地的三驾马车，即微服务、容器和 DevOps，三者相辅相成并有着宽泛的分割。在云原生技术落地过程中，利用麻利迭代和强壮运行的需要正是促成微服务利用产生并倒退的重要因素。而虚拟机作为 IT 基础设施的撑持，从单体利用到微服务利用的时代，曾经无奈很好地满足微服务利用部署的外围需要，即保障资源利用率不升高甚至晋升，高性能、高可用、高弹性的保障等。容器技术的衰亡并非偶尔，而是正好符合了微服务利用时代的需要。
云原生技术社区中最为人所认可的思想家之一，Adrian Cockcroft，他已经说过在与容器联合应用后，微服务架构的长处失去了进一步的放大。起因在于，微服务激励软件开发者将整个软件解耦为较小的性能片段，并且这些性能片段可能应答外界的故障。而容器进一步对这种解耦性进行了扩大，它可能将软件从底层的硬件中分离出来。
依据信通院《中国云原生用户调研报告》显示，国内 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 地址能够配置准确残缺的防火墙策略。
如果抉择 Overlay 网络计划，则须要通过 nodeport 或 Ingress 等非凡配置实现内外网互联互通，Overlay 网络计划更举荐微服务和中间件全副容器化的场景，其中跨集群的通信能够通过网络联邦来实现高性能的互联互通。
05 微服务和中间件都上容器，如何解决中间件容器化？
刚刚有讲过，在微服务和中间件都上容器的场景，除了网络选型，还有一个重点关注的内容，就是中间件的容器化。例如 MySQL、Redis、Kafka、Nacos 之类，这些中间件不光须要思考怎么容器化部署，还要进行包含全生命周期治理、可观测性、灾备、主动运维和无缝降级等中间件治理能力的建设。
既保障容器化的中间件的高性能高牢靠，同时也要实现具备更高的自动化运维能力。在这块，业界有一个根本达成共识的计划，即采纳 Operator，来对中间件的单实例 / 高可用形式进行主动部署编排，并提供相干的全生命周期和监控运维、备份复原的能力。
通过 Operator 来实现中间件容器化，或者说云原生化，相比于传统的中间件治理和运维计划，例如基于 ansible 的计划，具备特有的一些劣势。一是能够施展容器的高性能和高弹性，同时具备更强的自动化运维能力和疾速部署能力。当初社区里也有很多中间件的开源 Operator，但如果要做到真正的企业级落地，还须要做很多的加强。
例如，多版本、个性化指标、大规模数据迁徙，网络的高性能通信、安全可靠和运维排障效率高，存储也有高性能、耗费小、原地重启、智能编排、运维简略等要求，同时开源的 Operator 在跨数据中心的容灾双活和备份能力上也比拟不足。所以在理论落地中，这些问题都须要思考，要依据本人的应用场景和需要来正当抉择 Operator 以及是否要去做相干加强。
06 传统微服务如何向 ServiceMesh 演进？
在微服务利用应用 ServiceMesh 框架的场景中，有个问题绝大部分的用户都绕不过，就是现有传统微服务框架如何演进到 ServiceMesh 架构？咱们能够反过来想想，首先这个事有必要做吗？或者为什么要做？
这时候咱们须要先理解，传统微服务框架下存在的大量难以解决的痛点有哪些？
业务代码与微服务框架 SDK 强耦合（同一过程）；
业务降级与微服务框架降级强绑定导致微服务框架本身演进艰难；
大量语言独大停顿快，小众语言停顿慢带来的微服务框架 SDK 多语言并行开发与保护老本高；
异构服务框架难以共存实现渐进式演进，导致单体利用革新微服务利用的启动老本高；
繁多的语言限度了利用场景和人才的多样性，就如 Springcloud 次要反对 Java，对多语言反对比拟差。
而采纳 ServiceMesh 框架后，实现了业务逻辑与治理性能的拆散。在服务网格中，将治理能力下沉到基础设施后，业务的开发、部署、降级都和服务治理的基础设施解耦了。业务开发者能够专一本人的业务局部，只有没有批改业务代码，就无需从新编译和上线变更。当治理能力降级只需基础设施降级即可，基础设施的降级对用户业务齐全没有影响。咱们能够看到，ServiceMesh 计划具备多语言、多协定反对，无侵入、治了解耦和下沉、让开发更加规范化和难度升高等非常明显的劣势。
这时大家可能会有个疑难，传统微服务架构利用迁徙到 ServiceMesh 上，是不是很麻烦？
咱们在相干的我的项目实际和落地中，总结了两种常见革新计划，两者独特的外围是要去做解耦、剥离以及裁剪的事件。首先是流量治理的相干工作要通过 Envoy 等 Sidecar 来做，另外要思考的是要不要动业务代码自身。
一种比拟好了解，就是裁剪掉服务治理 SDK；另一种比拟激进的形式是只批改配置，SDK 仍然保留，但理论保留的次要是代码框架、利用协定等开发性能，波及到微服务治理的内容都卸载到基础设施去做。这须要原来的注册核心，治理等相干性能要借助 Kubernetes 和 ServiceMesh 去做，包含注册核心应用 kubernetes service 能力，间接应用 kubernetes 的服务名和端口拜访指标服务，联合本身需要，应用网格中的治理能力来逐渐替换原有的相干能力。
批改配置的形式须要手动的配置 ribbon，利用这种机制给对应微服务的后端实例地址中配置服务的 Kubernetes 服务名和端口。当 Spring cloud 框架中还是拜访原有的服务端微服务名时，会将申请转发到 kubernetes 的服务和端口上。这样拜访会被网格数据面拦挡，从而走到网格数据面上来。服务发现负载平衡和各种流量规定都能够利用网格的能力，就是说原来的 SDK 里的内容还在，治理组件什么的也还在，但被旁路掉了。这种形式能够实现代码 0 批改，不须要从新编译，实现真正的不侵入代码的转型和迁徙。
但裁剪 SDK 的形式，革新更彻底，从最终的镜像大小看，整个我的项目的体量也能失去极大的瘦身。这种形式客户依据本人的理论应用形式，进行各种裁剪，最终大部分是把 Spring Cloud 进化成 Spring Boot。这种形式会有肯定的代码革新工作量，并且须要从新编译。
这两种计划能够依据业务开发现状、规模和需要酌情选用。
说到微服务的治理和运维，咱们会关注”两个对立“。一个是微服务框架的对立治理，另一个是容器和非容器部署架构的对立治理。咱们的理论现状可能是一些利用是 Springcloud 框架，有些利用是 Dubbo 框架，有些是 ServiceMesh 框架，而这些利用有可能会局部部署在虚拟机局部在容器上。整体的、残缺对立的公布和运维管理体系的建设还是很有必要，否则又会产生多套治理平台，导致运维的工作量增大，运维效率也比拟低。
这是一个比拟典型的倡议，咱们举荐微服务的运维治理要做成异构化的撑持，蕴含监控和治理两块的内容须要思考。咱们能够在服务监控上做对立设计，服务治理能够在创立利用时抉择不同的架构进行不同治理计划的抉择，而后依据平台的对立治理组件治理能力或者 Sidecar 能力来实现不同的治理能力撑持。
07 对于博云
最初也简略介绍一下博云针对咱们明天探讨的场景，在产品和解决方案维度做了哪些事件。
针对企业微服务转型，博云能够提供微服务咨询服务，并且有相干的企业级产品微服务利用治理平台 BMS，笼罩开发、公布、运行阶段，同时提供中间件对立治理和企业级 API 网关等组件，并且具备在大量客户尤其金融客户那里积攒了丰盛教训的服务团队，能够提供一整套残缺的产品及服务解决方案。
在产品设计上，咱们以利用为外围，提供开发与公布视角的对立双模利用公布、治理、运维视角的对立监控，以及运行视角的多框架对立治理，真正实现了书同文、车同轨。
针对中间件治理场景，博云的中间件治理平台 BMM 基于开源 Operator 做了大量企业级加强，对于之前提到的开源 Operator 的一些有余，如高性能网络和存储的需要、跨机房的容灾备份需要等都做了全面设计晋升。目前曾经反对了 MySQL、Redis、Elasticsearch、Kafka、RocketMQ、PostgreSQL、Nacos、Zookeeper 等支流中间件的全生命周期治理能力。在多个我的项目的实际中，对于中间件交付效率的晋升、运维老本的升高、资源老本的节俭都有十分显著的成果。
在之前探讨到容器网络的两种网络模型，博云自研的 BeyondFabric 产品都能够提供残缺的解决方案反对，它联合了大量实际场景，从性能的完整性、高性能、稳固可靠性、易用性等多个维度做了全面设计。其中 Fabric Underlay 计划提供 pod 和 workload 的固定 IP 地址和地址段，多数据面治理，pod 多网卡多协定反对，通过 DPDK 和动静 qos 提供高性能低延时的撑持，在 IPAM 地址池治理场景，反对大规模 IP 疾速调配。
Fabric Overlay 计划提供网络联邦，在同构的联邦场景下提供高性能互通计划，不须要应用网关，另外提供多种隧道协定及隧道加密反对，能够提供分布式的 Egress 网关，在 namespace 和 workload 的级别均能够设置 eip。另外还有一些其余的外围能力，例如通过微分段的形式解决大规模集群流表性能问题，分布式控制器保障网络运行稳固牢靠，反对 windows 网络反对 arm 架构集群等，在这里就不一一赘述了。咱们在公众号上也有容器网络专题的文章，有趣味的敌人能够搜寻看一下。
明天的分享也到此结束，感激大家。