初探 Server-Mesh
前言
本次技术分享只做技术宏观思维与认知上的分享，具体配置细节与部署不在此次讨论范围。
讨论点：
1、微服务的局限性
2、了解 Server-Mesh 功能与实现方式
3、目前基于 Server-Mesh 而实现的 Serverless
我们最熟悉，最常用的 Java，Spring-Cloud，Spring-Cloud-Alibaba 等技术体系，归属于传统微服务的架构设计，此设计存在SDK强耦合问题，每次底层SDK版本的更新极大可能影响到业务层面的服务稳定性。SDK与代码环境强耦合，就会存在居多限制，不能完整的运用市面上不同语言与其对应的生态组件来做更擅长的领域，例如：灵活快速的Go，Python语言并对应其携程，爬虫，神经网络等等组件。严谨并且0垃圾回收的Rust语言，更适合企业级中间件高效率低内存占用场景。所以每种语言有它各自的优势与生态环境，以更长远的发展来看，大体量的龙头企业将会把业务部署与实现落地到不同的语言上进行迭代是一种趋势。
传统微服务体系图：
并且如今JVM引以为傲的跨操作系统优势，其特性也被K8S，Docker，Containerd，CRI-O，Kata 等容器技术与生态体系取代。垃圾回收机制，动态代理，Agent，ZGC等高级特性也被其他语言借鉴。目前来看支撑Java语言地位的是长年累计下来的生态体系（Apache，Spring，Ali，Huawei 等开源社区注入新的中间件，例如知名的： Kafka，Hadoop，Hbase，RocketMQ，Flink，Seata 等等，以及后续继续推出的中间件来保持语言生态的活跃），但随着时间的推移，长远看来（20-30年以上，主观预言，仅供参考），这些优势将可能被后起之秀所占据，下一代微服务体系势必将会在各类语言优势的基础上进行迭代更新。
个人思考：由于Java已被Oracle收购，但Oracle其公司并不是技术激进型企业，后续很有可能会限制住Java的发展，虽然有开源版本，但开源力量不如企业集中，目前IT界大佬Google的Go语言已经迅速崛起，并已占据Java部分市场。这可能也是字节，B站，腾讯，百度，京东，小米等企业选择的原因之一。
服务网格
简介
回到我们关注的 Server-Mesh （服务网格），Server-Mesh 目前主要的实现思维是 Sidecar（边车模式）来实现。K8S中我们用 Pod 来做基本部署单元，Sidecar 则是在一个 Pod 中部署其 Proxy 容器，Proxy 容器将会与业务 Server 容器部署在同一个Pod中（Pod容器注入），并且Proxy容器将会代理掉Server容器的所有流量。
Istio实现Server-Mesh架构宏观图：
citadel：负责身份认证和证书管理的核心安全组件。
galley：负责配置的管理组件，如验证配置纤细格式和内容的正确性，并将这些配置信息提供给pilot和mixer。
pilot：控制中枢，包含了服务发现和规则转化和下发。
proxy：有C++开发的Envoy与Pilot-agent实现，提供了动态服务发现、负载均衡、TLS、熔断、健康检查、流量拆分、灰度等功能，另外生成遥测数据，为微服务提供可观测能力。
Ingressgateway：入口处的gateway，即网格外访问网格内的服务就是通过这个gateway进行的。
通过Proxy容器，实现了业务代码与其SDK完全解耦，并且将获得许多功能特性：流量镜像，灰度发布，服务注册发现，远程调用，流量熔断，降级，链路追踪，平面控制，内网数据加密传输（分布式事务目前没有特别的解决方案，因为事务严格来说不属于服务治理层面）。并且对程序员来说完全透明，开发人员不需要了解其部署细节，几乎完全单机版开发，没有语言限制，不依赖任何微服务SDK。企业又可以选用不同的语言特性进行开发不同的功能模块（可能会带来更大的代码管理成本，沟通成本，团队掌握的语言更加广泛）。
官方Demo
官方Demo，Book-Info 微服务，可通过Heml一键部署K8S环境，即可体验其特性（Book-Info架构图）：
Bookinfo 微服务使用了 Istio 进行边车部署，使用了4种不同的语言程序，并且Java语言开发的Reviews服务提供了3个不同版本的应用，可以很好的体现出 Istio 在多版本控制，流量管理，流量迁移，整合等多方面能力。大家可以自己去部署下体验体验。可以很直观的感受到 Service-Mesh 的功能之强大，配置之灵活（都是秒级生效的配置，无感知流量迁移）。
市面上最常见实现
Istio
Istio是由 Google、IBM 和 Lyft 发起的开源的Service Mesh框架。该项目在2017年推出，并在2018年7月发布了1.0版本，截至目前2022-12-06 版本为 1.16.0 。Istio是Service Mesh目前的实现的典型代表，如果Sidecar是整个Service Mesh的数据面，那么Istio主要在控制面上做了更多的改进，Istio使用Envoy作为Sidecar，控制面相关全部使用Golang编写，性能上有了很大的提升。Istio 首先是一个服务网格，但是Istio又不仅仅是服务网格，在 Linkerd，Envoy 这样的典型服务网格之上，Istio提供了一个完整的解决方案，为整个服务网格提供行为洞察和操作控制，以满足微服务应用程序的多样化需求。
Karl Stoney
Linkerd2
Linkerd是Buoyant公司2016年率先开源的高性能网络代理，是业界的第一款Service Mesh框架。其主要用于解决分布式环境中服务之间通信面临的一些问题，如网络不可靠、不安全、延迟丢包等问题。Linkerd最初使用Scala语言编写，其版本Linkerd2使用Go与Rust重构。
Conduit
Conduit于2017年12月发布，作为由Buoyant继Linkerd后赞助的另外一个开源项目，作为Linkerd面向Kubernetes的独立版本。Conduit旨在彻底简化用户在Kubernetes使用服务网格的复杂度，提高用户体验，而不是像Linkerd一样针对各种平台进行优化。Conduit的主要目标是轻量级、高性能、安全并且非常容易理解和使用。同Linkerd和Istio，Conduit也包含数据平面和控制平面，其中数据平面由Rust语言开发，使得Conduit使用极少的内存资源，而控制平面由Go语言开发。
不同架构对比图
总结
Kubernetes的出现已经解决了运维中容器部署，高可用，多副本，容器迁移，弹性扩容，滚动更新，镜像版本管理，服务探活，计算资源分配，计算节点监控等的大部分问题，拥有着优秀的自动运维机制。但K8S在应用层Service容器上的监控与流量的管理，容器之间的相互调用，监控，注册，配置，浏览治理等功能并未提供。为了补充此功能模块则出现了Server-Mesh体系的技术，来扩展K8S在这方面的能力。使得微服务不再关注具体配置，环境细节，侧重关心业务功能实现，并且摆脱语言环境的限制。
Serverless
简介
随着微服务理念不断深刻人心，越来越多的企业把本身的应用逐步由单体转变成微服务架构，Container容器技术的出现也加速了这个转移过程，虽然它有效地解决了N多服务运行环境差异问题，可是随着服务数目的增多，容器的编排与管理成为了新的问题。Kubenretes的出现则解决了大规模微服务容器编排部署所带来的挑战，让整个行业意识到PaaS的落地能够成为现实。但当随着微服务体系下的容器数目愈来愈多，服务治理，流量管理成为必然要解决的问题，因而Istio出现了，基于网络代理与控制相分离的实现策略，容许对服务控制策略进行有效合理的管控。
架构的迭代到这里彷佛到了很美好的阶段：
- 微服务：解决应用内聚、臃肿的问题。
- Container：解决服务运行环境差异，和部署问题。
- Kubernetes：解决大量微容器编排管理，"聚合"部署问题。
- Istio：解决服务上线面临的，流量，发布，治理系列容器相关的问题。
这个阶段乍一看，构建容器云彷佛有了一个完整的链路和解决方式，一切都将变得那么"完美"。
但让我们回过头来深刻分析一下，微服务体系下的服务交互，目前是否存在问题。首先，不管是HTTP，还是RPC，本质上都是服务与服务的远程调用。开发应用程序中，没法做到服务与服务间的彼此透明。这样会致使一个问题：不管微服务业务拆分多么"精细"，本质上业务单元之间仍是不可以独立运行和迭代发展，没有彻底解耦。同时在面向不一样开发领域的衍生，没法选择最合适的实现方式。所以我们但愿可以基于不一样的"模板"，"配置"的方式可以把开发环境标准化处理，同时提供"事件"机制，将服务与服务交互的耦合度降到最低。其次，服务线上运行的动态伸缩问题。当下Kubernetes环境下的弹性伸缩，须要由客户搜集监测数据，并自主手动来实现，可是我们更但愿服务线上可以更加自动化和智能化。
最后，服务标准化问题。我们但愿服务内部的模型是标准的、可以快速复制和快速构建的；服务通讯是标准的：协议标准，格式标准；运行环境是标准的：快速部署，快速迁移。
于是Knative的出现刚好解决远程直接调用，服务线上自动扩容，版本快照以及一些列标准化解决方案。
Knative
由2018年 Google 推出 Serverless 世界的利器：Knative ，可在任何公有或私有云上实现无服务器架构，这样用户可以使用无服务器编程技术。目前参与的公司主要是 Google、Pivotal、IBM、Red Hat，于2018年7月24日对外发布，当前还处于快速发展的阶段。 与 Kubernetes 不同，K8S 需要始终运行至少一个 pod 实例才能为应用程序提供服务，而 Knative 可以扩展到零（冷热启动技术）。 然后，当客户端请求访问您的应用程序时， Knative 才开始实际运行应用程序的Pod。 这可以节省大量用于保持整年运行应用程序的费用。例如：访问不那么频繁，低频率使用的功能模块，可以考虑冷启动应用，以节约内存和计算资源（可通过技术手段优化容器启动时间，减少冷启动延迟【最快毫秒级启动】，目前国内做的最好的应该是阿里云）。
官网地址：
https://knative.dev/docs/https://github.com/knative
Knative 的目标是在基于 Kubernetes 之上为整个开发生命周期提供帮助。它的具体实现方式是：首先使你作为开发人员能够以你想要的语言和以你想要的方式来编写代码，其次帮助你构建和打包应用程序，最后帮助你运行和伸缩应用程序。Knative 主要由 Build、Serving 和 Eventing 三大核心组件构成。Knative 正是依靠这三个核心组件，驱动着 Knative 这艘 Serverless 巨轮前行。
Build （编译系统）：
- 内部构建：它的构建完成是在 kubernetes 中进行的，快速的把函数编译上线，与整个 kubernetes 生态结合更为紧密。
- 标准化：它旨在提供一个通用的标准化的构建组件，可以作为其他更大系统中的一部分，部署脚本标准化结构化，可更好的将服务进行迁移部署。
Serving （服务系统）：
- 快速部署：快速部署 Serverless 容器
- 按需扩容 ：支持自动扩缩容和收缩到 0 实例
- 路由策略：基于 Istio 组件，提供路由和网络编程
- 版本快照：支持部署快照 （生产环境容器快照，可长期保存，并任意恢复到某个快照版本）
Eventing（事件系统）：
Source(源)、Channel(通道) 、Subscription(订阅)
事件系统使得生产和消费事件变得容易，抽象出事件源，并允许操作人员使用自己选择的消息传递层。Serverless 中最重要的是基于事件的触发机制，也就是说当某件事发生时，就触发某个特定的函数。事件概念的出现，让函数和具体的调用方能够解耦。函数部署出来不用关心谁会调用它，而事件源触发也不用关心谁会处理它，简而言之，在我们的代码中并不需要去书写具体调用方Service，只需要关注事件发送与处理事件即可（相信对MQ队列熟悉的人已经心里有底了，不过Eventing的事件系统更加完备一点，有多种事件处理模式），我们Service在远程RPC或HTTP调用时，不需要关注具体服务实例，也不需要去订阅注册中心，只需要发生事件源即可，具体事件的返回数据全部由Eventing给我们完成。真正实现了服务间的透明，解决了服务耦合问题。【正所谓耦合与解耦往往只是差了一个中间层】
整体优势
便利性：Knative 以 Kubernetes 作为其底层框架，因此无论是线上还是线下，任何 Kubernetes 集群，无论是云上 Kubernetes 服务还是自建 Kubernetes 集群，都可通过安装 knative 插件快速的搭建 serverless 平台。
标准化：Knative 联合 CNCF，把所有事件标准化，统一为 CloudEvent，提供事件的跨平台，同时让函数和具体的调用方能够解耦。
服务间解耦：使用 Knative 使得应用不在与底层依赖服务强绑定，可以跨云实现业务互通。
成熟的生态：Knative 基于 Kubernetes 体系构建，与 kubernetes 生态结合更紧密。
自动伸缩：监控应用的请求，并自动扩缩容, 借助于 istio (ambassador,gloo等) 天生支持蓝绿发布、回滚功能，方便应用发布流程。
应用监控：支持日志的收集、查找和分析，并支持 VAmetrics 数据展示、调用关系 tracing。
快照部署：对每次发布的服务记录其快照信息，并可长期保存，可在任意时间节点无感知的恢复到某个快照版本。
总结
Serverless（无服务器架构）成为了目前新的技术热点，Serverless 是在传统容器技术和 Server-Mesh 服务网格上发展起来。无服务器云函数可以让开发者无需关心服务器的部署运营，只需开发最核心的业务逻辑，或者函数，即可实现上线运营，并自动具备分布容灾能力，依据负载自动扩缩容，在公有云中按照实际调用次数，执行时长，计算资源消耗来计费，做到没有计算资源浪费，更好的节约企业开销。
Serverless 大体上可以分为两种类型：【BaaS 是后端即服务，FaaS 是函数即服务】
BaaS：无服务器首先用于描述显着或完全包含第三方云托管应用程序和服务的应用程序，以管理服务器端逻辑和状态。这些通常是“富客户端”应用程序 - 认为单页网络应用程序或移动应用程序 - 使用庞大的云可访问数据库生态系统（例如，Parse，Firebase），身份验证服务（例如，Auth0，AWS Cognito），以及等等。这些类型的服务以前被描述为 "后端即服务"，也就是我们的Spring-boot，Tomcat，Dubbo，Weblogic，Gin，Flask等等后端常用的容器与服务中间件。
FaaS：无服务器也可以指服务器端逻辑仍然由应用程序开发人员编写的应用程序，但是，与传统体系结构不同，它在无状态计算容器中运行，这些容器是事件触发的，只需要实现一个函数，无需关心其他环境，短暂的（可能只持续一次调用），并且完全由第三方。想到这一点的一种方法是"作为服务的功能" 或 "FaaS"。国外 AWS Lambda 是目前功能即服务平台最受欢迎的实现之一，国内目前提供 Faas 服务的有阿里云上 FC 函数计算服务。
简而言之，无服务器架构的出现不是为了取代传统的应用。而是从具有高度灵活性的使用模式及事件驱动的特点出发，它可以帮助我们达到减少部署、提高扩展性并减少代码后面的基础设施的维护负担，为我们提供更多的可能性去更好的选择适合企业的部署方案。
后续思考
1、未来的部署架构会是怎样发展，其高可用，高性能，高并发 3H的特性将会如何衍生新的技术体系，企业部署的私有云可靠性如何去做到 6-12个9 的可用性【6个9：(1-99.9999%)*365*24*60*60=31秒，一年停机时间不能超过31秒，但12个9可就是不小的挑战，从企业成本角度来说是没必要的，甚至不可能去实现，一年停机时间不能超过(1-99.9999999999%)*365*24*60*60=0.00003秒】，配合异地多活的架构体系，又可以衍生出多少新的中间件技术呢？
2、这种架构就只有优点没有缺点吗，其开销与体量，可控性是否适合所有企业？企业抛开业务场景上来直接Serverless体系是否科学？
3、有没有发现软件上的容器生态技术，与硬件超融合技术有异曲同工之妙，其目的都是弹性，迁移，节约成本，灵活，敏捷，更可靠？
如有不足欢迎各位补充，留言交流。