云原生时代，微服务和云原生是什么关系？云原生时代的微服务有哪些特点？目前活跃的微服务项目有哪些？阿里巴巴资深技术专家李想，从微服务生命周期、流量治理、编程模型、可信安全等方面分享他对微服务与云原生关系的理解。2010年左右开始出现微服务架构和云原生微服务，一开始大家会把微服务架构应用在传统的IT基础设施上，也就是传统的IDC或者物理机上。我们使用这些物理机器为我们的微服务架构提供资源，形成一个分布式系统，相互协作，协同。随着我们整个IT基础设施的发展，我们也逐渐进入了云时代。我们迈入云时代的第一步是云托管，即用云上的虚拟机和云上的虚拟弹性资源代替传统IDC中的物理机。其实微服务架构的变化并不是很大。.我们可以很方便地将原本部署在物理机上的架构模型迁移到托管在云端的虚拟机上，也叫LiftandShift方式。同时，在云托管时代，我们也尝试更好地利用云上虚拟机的弹性能力来做微服务的自动水平伸缩。随着技术的进一步发展，云原生时代有何不同？云原生希望通过微服务、DevOps、协作等架构和理念，更好地与云提供的服务、能力、平台进行整合和协作。我们希望云不仅提供弹性的物理资源，如存储、计算、网络资源，还希望为微服务提供更好的运行环境和平台。这就需要我们做以下两件事：资源层面的联合优化，更好的利用资源。充分利用云服务和平台，大大提高了研发和运维效率。这其实也是CloudNative想做的，就是让我们的微服务架构和系统能够以最好的方式和云端以及基于云的服务和平台协同工作，降低成本，提高效率。2.微服务与云原生如果以微服务为中心来看微服务与云原生，我们可以从四个点来谈谈它们之间的关系以及微服务在云原生时代的演进。生命周期管理。交通管理。编程模型。值得信赖和安全。从本质上讲，微服务就是将一个单体应用从一个巨型应用拆分成若干个更小的服务，并协同完成原单体应用所提供的对等业务服务。因此，服务与服务之间会存在依赖关系，服务也需要部署到一个或多个资源上。如上图所示，可以看到原来的单体应用和资源的关系其实是一对一的关系，单体应用的协同也是一些内部协同，没有外部动态依赖.而当我们切换到微服务时，我们可以看到这张图会变得网格化和复杂化。因此，由于内部原因，超过50%的企业会认为微服务架构或采用微服务架构，而最大的挑战在于更复杂的运维，即更复杂的生命周期管理。今天我们讲的是云原生的基础——容器和容器服务，就是帮助微服务解决生命周期管理和运维管理问题。如何解决？我觉得分为两部分：第一部分，不同的微服务之间可能存在一些异构性。为了让每个团队在微服务体系下发挥最大效能，我们让不同的团队使用不同的编程语言，甚至不同的运行环境来运行这些微服务。因此，我们在运维和管理微服务时，最初并没有一个统一的标准来应对异构环境。这也是后来容器的云原生技术火起来的原因。它的一个重要功能是通过一层标准的封装和标准的运行时来规范微服务部署。这样，从生命周期管理的角度来看，各个微服务之间的差异点会更少，共同点会更多。在这个技术的基础上，我们后来又发展了一层：容器平台，现在也很流行，比如Kubernetes。它的作用是帮助最方便地在底层资源上运行标准化的微服务。我们提到的存储、计算、网络都是通过Kubernetes层进行抽象和封装，使得经过容器统一的微服务可以直接运行在Kubernetes平台上。因此，运维人员不再需要为如何将某个微服务分配给特定的资源或计算单元而烦恼。通过容器和容器平台，大大简化了微服务本身的生命周期管理，简化了微服务本身的运维管理问题，促进更多的微服务被企业采用。如果从更微观的角度来看，容器和容器平台对微服务的生命周期提供什么样的帮助？例如，Kubernetes引入了一个非常有趣的概念，叫做pod。Pod实际上是容器的集合。一个或多个容器可以在一个pod中运行。一般来说，当我们采用微服务架构时，我们会将微服务的主体运行在主容器中，而主容器的生命周期与pod本身的生命周期是耦合状态。此外，我们还会运行一些sidecar容器或Sidecar容器，为主容器提供一些辅助功能，比如日志收集、网络代理、身份认证等。我们可以都放在一个Sidecar容器里，让微服务有Superpower，一个超能力。除了它提供的核心业务服务，我们还可以加装盔甲，即动态添加一些额外的辅助能力，让微服务管理越来越强大。另一方面，其实pod模型也提供了一些非常有用的功能：状态信息。Pod会提供一个标准的界面来显示运行状态。例如，是否准备好接收流量？如果它准备好接收流量，来自入口的流量就可以到达微服务。如果运行状态不好，我们可以尝试修复、重启或删除容器，甚至切换到另一个计算单元运行，这为微服务的整体稳定性提供了保障。地址服务。每个Pod都有一个标准化的DNS地址服务，可以统一寻址。这对于需要统一暴露的API的日志记录、监控和跟踪能力非常有帮助。可以根据DNS地址访问pod暴露的可观察性信息，方便及时发现运行时问题。所以我们可以看到，容器平台和容器其实是帮助微服务在微观层面拥有更多的能力、更强的健壮性、更好的可观察性。这里，如上图所示，在微服务运行时方面，容器平台也提供了非常有效的能力，帮助我们做Day2微服务的更新、发布、扩容等操作。例如，Kubernetes提供了几种典型的升级或扩展策略：滚动部署、蓝绿发布等，有效简化了我们的运维工作，提高了运维本身的确定性和自动化效率。总而言之，在生命周期方面，通过使用容器和容器平台技术，我们大大提高了容器生命周期控制的标准化和自动化程度，节省了人力成本，提高了效率，让更多的企业愿意使用微服务这一技术。一方面，流量管理微服务是通过架构拆分，将原本静态编译时产生的能力与能力之间的关系推导到动态运行时。因此，在运行时，需要服务之间的通信和协作来完成特定的业务功能。大家在沟通协作的时候，需要对沟通过程进行管理，也就是对流量进行管理。例如，我们需要知道如何从一个微服务中找到另一个微服务，以及如何确保一个微服务找到最好的微服务实例与之通信。这是一个比较复杂的过程，包括RPC能力、服务注册Discovery能力、动态配置管理能力、服务降级能力等。为了减轻业务开发同学的负担，不需要在每个微服务中重复写微服务流量管理的通用能力，所以我们开发了很多框架。比如在Java系统中，大名鼎鼎的SpringCloud提供了分布式微服务服务管理框架；在Go语言的开源生态中，也有GoMirco这样的系统；在阿里巴巴内部，我们也有像HSF这样的系统开发的微服务治理框架。因此，从抽象层面上，我们可以看出一个服务包括两个层次：一个层次是它自己的业务逻辑，也就是微服务业务开发者编写的代码，功能实现是和业务实现相关的。另一个层面是实现微服务与微服务之间通信、流量、服务治理的代码。我们将其抽象成一个框架，比如下图中标注的SpringCloud。这样的抽象带来了一个问题，就是所有的通用能力都依赖于这个具体的框架。假设在公司里，除了SpringCloud，我们还引入了其他的服务框架，比如AlibabaHSF。如果你想和写在SpringCloud框架上的微服务通信，应该怎么做呢？这就需要HSF和SpringCloud互通，协议之间相互理解。但实际上，这些框架往往不具备这种能力。一个更大的问题可能是在云原生时代，我们允许这些微服务的开发可以用不同的开发语言和模型来编程。因此，框架之间的体系不是一对二的关系，也不仅仅是SpringCloud和HSF的关系。可能是Java系统与JavaScript、Python、Go系统等微服务框架之间需要打通的问题。解决微服务在多语言、复杂环境下的治理和管理问题，已经成为一个NtoM的问题。这时候，当我们有了容器、容器平台、pod等抽象，可以提供一个平台，而不是完全依赖业务中的代码或框架时，有没有更好的方法来解决刚才提到的问题呢？现在有一个流行的概念叫做ServiceMesh——服务网格。其本质是为了更好地解决多语言、多环境场景下的流量管理问题。其主要思路如下：一是将流量管理的框架能力从业务耦合的二进制中抽象分离出来，形成一个独立的流量管理进程，以Sidecar的方式部署在Pod中。通过操作系统层面的透明流量劫持，将所有微服务之间的流量劫持到Sidecar中，再通过Sidecar与Sidecar之间的通信进行流量转发和管理。这样一来，问题就简单多了。我们只需要让流量管理sidecar可以相互通信，并且能够相互通信即可。目前比较知名和流行的开源流量劫持和管理Sidecar实现叫做Envoy。当然，光有这一层的流量劫持和管理是不够的，还需要控制面的支持。例如，原有微服务系统的服务注册、服务发现、流量观察等仍然需要，需要将这些策略和规则下发给sidecaragent进行流量管理。因此，我们还需要构建一个控制平面来管理部署在Pod中的流量管理的数据平面的单点，让它们形成一个mesh，形成一个集群。因此，我们需要具备一些管理控制平面的能力。Istio是开源中比较流行的控制平面实现之一。主要实现三个能力：流量配置、流量安全、流量观察。我们相信，在云原生逐渐平台化的时代，大多数新的应用和场景都会尝试使用基于ServiceMesh的技术进行微服务流量管理。编程模型是请求驱动的，即支持基于请求的动态弹性伸缩，简化请求处理逻辑。有的同学可能会把这个模型称为Event-driven，即事件驱动，但是request-driven其实是事件驱动的一个分支。什么是请求驱动？从传统的微服务架构来看，当一个外部系统请求进来的时候，通常会经过一个L4/L7的负载均衡，然后交给不同的微服务实例。同一个微服务实例本身的流程内部，一般有两块逻辑。第一个逻辑是请求管理，可能是一个HTTPServer和一些Handler，具有一些队列管理和请求分发等能力。这些请求最终会被提交给第二个逻辑部分，Processor，也就是真正的请求业务处理逻辑，去实际处理和响应这些请求。这种架构会带来两个问题：请求管理的逻辑必须在不同的微服务框架实现中重新编写，比如Java、Go或Python，都有自己的请求管理逻辑。请求管理和请求处理形成耦合关系。因此，在这种架构下，没有全局独立的控制层可以感知请求并进行流量管理。这个请求只能在微服务实例本身的处理层进行解析。此时即使微服务实例过载，也很难将请求转发给其他微服务实例进行负载均衡。请求驱动系统就是试图解决这两个问题。我们尝试在微服务中做一个请求驱动的解耦操作。首先，规范从外部系统传输的请求。我们有一个适配器。标准化后，放入请求负载均衡器。这个负载均衡器已经可以理解请求本身的语义，它可以驱动请求处理。请求处理的逻辑。当请求处理单元不够时，可以使用请求处理管理器扩容；当请求处理逻辑单元较多时，还可以降低容量，节省成本。此外，开发者不再需要实现请求管理逻辑，降低了开发成本。刚才提到的请求驱动模型可以分为三个部分：请求的标准化、请求的路由、请求的处理。说说Serverless的概念。这也是微服务系统和基于平台的Serverless系统整合的一个过程。Serverless平台有阿里云FaaSS和SAE，AWS有Lambda，Google有CloudRun，Azure有Functions。如果你希望能够搭建一个serverless平台，比如请求标准化，也有开源的请求标准比如CloudEvents，Knative处理路由和请求处理水平扩展组件，你可以使用Kafka或者RocketMQ来做持久化请求本身和请求本身的转发。分布式运行时在编程模型的分布式运行时，我们希望微服务能够有更好的多语言环境支持、环境可移植性和极速启动。在多语言支持、环境可移植、单体应用快速启动的时代，我们的业务代码与中间件代码耦合在一起，是部署的实例；经过流量管理，我们可以看到我们的业务代码和流量管理代码其实是可以分离的，只是中间件的一部分代码还是和一部分业务代码耦合在一起，形成一个二进制。为了实现足够的多语言支持和环境可移植性，我们希望将剩余的中间件代码与业务解耦。这种技术称为运行时解耦。其基本思想是为业务代码提供标准的可扩展API，是一个支持多语言的轻量级API。通过调用API实现中间件功能，我们把中间件能力当做流量管理，也下沉成一个Sidecar，用一种语言统一实现，然后设计可插拔的模式，让大家可以插入更多的中间件能力。Dapr技术的领先实践之一是微软去年推出的名为Dapr的分布式运行时。Dapr向业务代码暴露了两个API，一个是HTTPAPI，一个是grpcAPI。这两个API非常轻量级，可以跨越多种语言。Dapr本身作为分布式运行时，可以对接多种中间件系统，通过标准的API屏蔽不同系统之间的差异，提供一定的编程接口interface统一。在代码实现上，将中间件代码从应用层抽取出来放到Sidecar中。如上图所示，我们只需要在业务上编写业务代码，其他代码几乎全部由基于Dapr的平台接管。Dapr本身分为两部分：第一部分是Dapr暴露给Application的API，另一部分是Dapr的框架层。通过Dapr的framework层，我们可以接入各种Dapr相关的实现：Kafka/SQS等Resourcebandings，Redis/cassandra等管理数据，或者我们做RabbitMQ等Publish&Subscribe，甚至是Prometheus/OpenTracing等DistributedTracing等，可以接入Dapr的框架，再通过统一标准的HTTP和gRPCAPI提供给业务代码和应用代码，从而实现更完善的业务代码、中间件、流量管理能力与解耦，应用开发者也可以更自由地专注于业务代码开发。可信安全因为微服务与微服务之间需要进行网络通信，所以需要安全可靠的认证。传统的做法是将微服务放在一个可信的网络环境中，假设网络环境中的所有通信、执行的应用程序或微服务都是可信的，它们可以自由地通信或交换，并且可能有一些轻量级的认证和授权来进行一定的安全性防范措施。但这种模式会带来风险。当一个微服务入侵可信网络时，会给整个微服务系统带来很大的安全风险，因为可信网络内部的防御在一定程度上是比较薄弱的。缺乏。此外，可信网络与可信网络之间经常存在微服务相互调用或认证的问题。常见的解决方案是通过VPC对等或者通过网关网络的gateway开启。使用可信通道确保微服务之间在网络级别的可信调用。但这也会导致一个问题。例如，如果在另一个可信网络中被入侵，它可以攻击其他连接的可信网络，这也增加了被攻击的可能性。在微服务时代，我们思考是否有更好的解决方案，而不是假设网络是一个完全可信的环境。因此，提出了一个概念，称为微服务或应用程序可信安全。也就是说，微服务与微服务或机密文件之间的每一次通信都是基于身份系统的。微服务将为与之通信和协作的目标对象提供身份认证。就像我们通过浏览器访问HTTPs网站一样，这些网站需要提供证书，我们的微服务也需要提供自己的身份认证，让接收方通过平台进行认证和查看授权。只有通过这些认证，才会开始与微服务的通信。实际上是利用平台的特点，在网络层构建以应用为中心的基于统一身份认证和授权的系统。但是这个系统的构建难度还是比较大的，也就是说在一个不完全可信的网络中，需要一个可信的平台层或者中间层，类似于PKI中的CA机制。以HTTPs为例，如果我们要信任一个CA，我们可能需要提前在操作系统中预置证书，并且必须从安装时就预置，以提供更安全的端到端可信度，否则无法为这条信任链建立良好的关系。同样，在云环境中也需要这种机制。云本身就是一个可控的平台。通过云端底层的硬件机制，到运行在云端的OS，最后到向上部署微服务的平台层，我们要建立一个可证明的信用链。为每个微服务提供自己的身份ID和授权可验证的授权信息，使微服务提供统一的可验证可验证身份。也就是说，在云原生时代，平台思维可以为微服务安全提供更大的价值。此外，平台之间或者网络之间，也可以通过平台级的可信信用建立关联关系，使得不同平台之间的微服务也可以产生信任关系。为了连接不同的平台，有一个名为spiffe的开源项目，它提供了一个统一的标准身份ID以及如何以统一的方式证明和认证授权信息。三EDAS其实上面说了这么多，可以发现开源开放领域不断衍生出新技术，不管是微服务流量管理相关，还是微服务生命周期相关，或者微服务的可信度对于安全和编程模型，如果你尝试自己构建这种能力或平台，一般会花费大量的时间和精力。为此，阿里云最近升级了云上的服务——EDAS。它将EDAS从传统的基于云原生基础设施的面向微服务的管理系统，转变为提供容器生命周期管理和微服务的云原生应用PaaS。治理、可观察性、安全流量管理等能力让阿里云用户无需花时间搭建这样的平台，就可以最大限度地发挥云原生时代微服务的优势。因此，建议对云原生微服务感兴趣的同学可以尝试使用EDAS。四云原生微服务云原生时代，微服务的特点：平台化，以云为平台，如微服务架构为更多赋能。标准化，我们希望微服务本身的部署运维，以及微服务与其他服务之间的通信可以标准化，让服务之间的互联变得更容易，服务可以跨越不同的平台，可以一次编写，定义一次，并在多个地方运行。微服务是轻量级的，让研发人员关心核心业务代码和业务逻辑的开发，而不是微服务治理相关的复杂逻辑开发。微服务产品化。我们希望打造微服务相关的产品，支持大家以产品化的方式使用微服务架构，让其更易用，更好用。五全球开源微服务框架活动报告我们最近花了很大的精力收集了一些在云原生时代比较活跃的微服务项目，然后发现了几个特点：quarkus是一个非常活跃的项目，可以帮助Java或者Java生态系统要尽可能轻量化，适应我们在云原生时代对弹性和高效启动速度的要求。SpringCloud的上升趋势还是很不错的。作为Java中非常典型的微服务框架，我们也在阿里巴巴的SpringCloud生态中深耕细作。现在最流行的SpringCloud云服务商是SpringCloudAlibaba。最后，像Dubbo，还有阿里投入大量人力打造的Dapr项目，其实还是比较活跃的。
