身为程序员，就应该了解微服务的未来发展趋势：云原生应用架构

Posted 2023-04-08 该用户快成仙了

微服务发展趋势

随着Docker技术的普及和Kubernetes在互联网公司的大量部署与使用，微服务架构正在围绕应用如何易于开发交付、减少资源消耗、无侵入治理等方面进行变革和演进。

本篇我们将讲解云原生架构、Service Mesh技术、无服务器架构（Serverless）技术。

云原生应用架构

云原生应用架构的3个特征包括：容器化、微服务、DevOps。

通俗地讲，就是将现代应用基于微服务架构原则（云原生12因子）构建，使用DevOps开发运维一体化的动态管理机制，将微服务自动化部署在私有云或者公有云。

云原生应用架构进阶

Pivotal是云原生应用的提出者，推出了Pivotal Cloud Foundry云原生应用平台和Spring开源微服务框架。

近几年，随着云原生生态的不断发展壮大，Google主导成立的云原生计算基金会对云原生做了重新定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。

云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

CNCF对云原生的定义从Cloud和Native两个方面进一步阐述。

● 一方面，强调Cloud代表着应用的运行时，运行环境基于私有云、公有云或者混合云等，有别于传统的数据中心机房环境。

● 另一方面，Native应用是适合云环境的微服务程序，这些微服务程序更加适合运行在云端环境。

下面我们从应用、平台、组织流程等不同视角来看云原生应用架构的演进过程，以及云原生架构相比传统应用软件开发模式的组织特征和架构特性，示意图如下：

 从云平台搭建开始

云平台相比传统的IT运维方式具备成本低、弹性、可靠性、便捷性等特性，而这些显而易见的优势都成为企业转型使用云平台的重要因素。

业务微服务化转型

企业进行云原生架构转型的核心动力是快速响应业务的需求和变化。传统的单体架构成为业务发展的羁绊，微服务给应用开发及部署带来了极大的灵活性和可扩展性。

持续的价值交付

持续交付需要基于DevOps方法论，结合持续集成和持续部署（CI/CD）过程完成应用持续的价值交付，从而使业务能从云原生技术架构中得到持续的价值收益。

Java的云原生应用优化

云原生应用围绕性能（Performance）、稳定性（Stability）、安全（Security）、扩展性（Scalability）等特性持续迭代演进。

在企业应用开发领域，使用Spring Boot为代表的开发框架作为云原生应用开发框架，依然处于主流地位，但是同样存在诸多劣势。

我们可以从以下几个方面考虑优化应用性能。

编译速度优化

Spring Boot在2.3.0.M1版本中对默认的编译工具进行了重大更改，使用Gradle而非Maven作为构建项目的主要代码管理工具。SpringBoot团队考虑切换到Gradle的主要原因是减少构建项目所需的时间，提升编译的效率。

相比Maven，Gradle在依赖管理、多模块构建、插件机制等多方面特性都有更加显著的优势。Gradle使用XML方式进行配置，把“约定大于配置”的设计理念进一步发扬光大，最重要的是并行化的编译速度有显著的提升。

镜像瘦身

交付物打包体积的大小直接影响镜像的分发和传输速度，通过对Docker镜像瘦身，可以显著提升构建交付物的效率。

分阶段构建则通过将构建环境和运行环境分离，减少上述构建产生的镜像冗余问题。下面列举了使用两阶段进行打包构建的方式。

 从上述DockerFile可以看到，我们将镜像构建分成两个阶段。

● 构建（Build）阶段依然采用JDK作为基础镜像，并利用Maven进行应用构建。

● 发布镜像阶段，我们采用JRE作为基础镜像，并从“Build”镜像中直接复制出生成的打包文件。在发布镜像阶段，不包含任何编译时的依赖，减少了镜像体积。

提升启动速度

JVM 9引入了AOT编译方式，它会将JVM编译结果保存在SCC中，在后续JVM启动中可以直接重用。与启动时进行的JIT编译相比，从SCC加载预编译的实现要快得多，而且消耗的资源更少，启动时间也得到明显改善。使用方式就是在OpenJDK的启动参数中增加参数配置：

-Xshareclasses开启SCC，-Xquickstart开启AOT。从测试结果来看，使用OpenJDK的SCC和AOT特性启动速度提高了50%；而JVM资源占用也减少了400MB左右。

Java云原生框架探寻

Java云原生框架在社区中出现了一些技术框架的探索，其中比较典型的代表是Quarkus和Micronaut。二者都可以运行在GraalVM上。

GraalVM使AOT编译成为可能，将字节码转换为本地机器代码，从而产生可以本地执行的二进制文件。

本文给大家讲解的内容是微服务发展趋势，云原生应用架构

1. 下篇文章给大家讲解的内容是微服务发展趋势，Service Mesh技术
2. 觉得文章不错的朋友可以转发此文关注小编；
3. 感谢大家的支持！

云原生应用和微服务发展主流趋势

　　今天谈下对为微软开源的Dapr框架的初步理解，实际上对于Dapr去年就经常看到相关的新闻和技术材料，但是由于是微软发布的开源产品一直没有引起我重视，最近又经常看到Dapr这个微服务框架，才仔细去学习了相关的资料。

　　微软Dapr框架概述

　　Dapr 是微软主导的云原生开源项目，2019年10月首次发布，到今年2月正式发布 V1.0 版本。在不到一年半的时间内，github star 数达到了 1.2 万，超过同期的 kubernetes、istio、knative 等，发展势头迅猛，业界关注度非常高。

　　Dapr 这个词是是 「Distributed Application runtime」的首字母缩写，非常精炼地解释了 dapr 是什么：dapr 是一个为应用提供分布式能力的运行时。

　　什么是 Runtime

　　Runtime 是一个抽象的概念，字面意思是程序运行的时候。一般是指用来支持程序运行的实现。描述的是程序正常执行需要的支持：库、命令和环境等。

　　常见的 runtime 为程序提供的支持　　

语言 runtime（C/Goang…）操作系统：交互，垃圾回收，并发控制等 .NET runtime: 虚拟机 容器运行时：namespace，cgroup 等

　　容器运行时，就是容器运行起来需要的一系列程序和环境。比如如何使用 namespace 实现资源隔离，如何使用 cgroup 实现资源限制，这些都是容器运行时需要提供的实现。

　　什么是 Distributed Application Runtime

　　Dapr 所提供的「分布式应用运行时间」，是应用程序运行所需分布式能力的实现，这些能力涵盖服务通信、数据持久化、外部 binding，pub-sub 等等。比如服务调用需要有容错重试机制，比如一个数据持久化操作希望使用乐观锁，比如发布消息是要求有投递保证。

　　长期以来，这些功能的适配都是集成在业务代码里的。dapr 创新之处是将这些功能，从原来 application runtime 中拆分出来，作为一个独立的 runtime。dapr runtime 也满足上面说到的 runtime 的特征。

　　简单总结就是：

　　Dapr是一种可移植的，事件驱动的分布式运行时，企业开发者通过它可快速地构建弹性的、有状态或无状态的微服务应用，这些应用可运行在云或边缘，并支持语言与框架的多样性。同时开发人员只需要关注业务功能和逻辑的实现，而对于应用本身的底层高可用性，可靠性和弹性伸缩能力并不需要去关注，而由云原生平台来解决。

　　Dapr本身是跨语言, 跨框架, 跨环境的。Dapr是平台无关的，这意味着你可以在本地、任何Kubernetes集群以及其他集成Dapr的托管环境中运行，这可以让你的微服务应用运行在云或边缘节点上。使用Dapr，你可以使用任何语言、任何框架构建你的微服务应用，并将它运行在任何环境中。

　　Dapr架构

　　Dapr 的设计是典型的分层架构，其核心理念，是利用抽象层来实现应用关注点的分离，用以降低分布式应用的复杂性。在 dapr 的架构中，核心的三个组成部分：　　

• API

• Building Blocks

• Components

　　对于这个图，我不准备引用官方文档的一些说明，从Dapr的分层架构上，可以简单地理解为北向接口和能力开放，内部业务组件和逻辑实现，南向底层能力适配三个方面的内容。

　　对于最上层的API层是最容易理解的，即将内部组件能力发布为API接口服务，既可以是Http Rest API接口，也可以是Rpc接口，而且可以做到灵活发布给前端应用使用。

　　对于Building Blocks，除了架构图里面谈到的状态管理，资源绑定，发布订阅，可观测性等能力外，更加重点是是和能力绑定在一起的核心业务组件和功能实现。也就是Building Blocks仅仅是核心逻辑组件实现附属的Sidecar能力。核心组件能力如何实现呢？你仍然可以按照传统的编程语言来实现你的核心业务规则和逻辑。

　　对于Components层，实际是一个关键，核心就是提供和底层云原生基础设施，和边缘端的对接和适配能力。这个能力从最早期的云原生基础设施资源层，进一步抽象到当前主流的PaaS技术服务层，或者理解为前面谈到的Runtime运行时能力对接，典型的就是数据库，中间件，消息，缓存等各种能力对接。

　　开发模式和API调用

　　上图实际是对Dapr开发机制的一个关键说明。

　　既开发人员重点是开发业务功能和逻辑实现，而且整体应用的开发以及从资源层抽象到服务层，既开发人员直接对接的是服务和运行时，而不是自己去安装和配置资源。

　　你原来需要数据库能力，原来思路是你自己去找到资源并安装配置数据库，而新架构模式下思路是你直接使用数据库服务，在底层数据库资源和功能开发之间通过Components来进行适配，这个适配不仅仅是从资源层到服务层的抽象，更加重要的是可以扩展云原生下多云服务适配能力。

　　对于API接口的开发和暴露，同样对于组件来讲暴露Rest API接口或RPC，而对于前端应用开发既可以调用标准的Http Rest API接口，也可以在前端应用中下发一个轻量的SDK包作为Sidecar适配，彻底实现前端和后端之间的解耦。

　　Dapr和ServiceMesh，ServerLess的融合

　　对于Dapr，个人更加倾向于将其理解为ServiceMesh和ServerLess能力的融合。

　　Dapr和ServiceMesh在微服务治理里面都是通过Sidecar边车模式来实现。但是可以看到对于ServiceMesh更多是偏微服务治理方面的能力，包括了注册发现，限流熔断，安全，负载均衡等能力，这种能力可以理解为各个微服务之间的横向交付能力。

　　但是对于Dapr来讲，不仅仅是提供微服务间的横向交付能力，还提供微服务本身在纵向将资源，服务，接口，前端应用分层后的纵向交互能力。即Dapr提供了完整的分布式运行时能力，这个能力提供既提供了南向对于底层云端资源，边缘端能力的集成和适配；同时又提供标准的API层能力接口和开放，实现和前端功能的集成适配。

　　再来看下ServerLess无服务器架构。

　　对于BaaS层后端即服务能力，实际和Dapr架构里面的Components组件层完全对应，即将底层的资源层能力抽象为运行时的服务层能力。

　　但是对于ServerLess的无服务器架构，BaaS层更多的是类似数据库，消息，缓存，存储，日志等各种技术服务能力。因此常规的云原生平台提供的ServerLess并不适合开发企业级的复杂应用，其核心原因就是共性的领域层业务服务能力无法提供。

　　那么如何来解决这个问题？

　　简单来讲就是ServerLess的架构思路，仍然需要和微服务架构进一步融合。既借鉴ServerLess的资源，分层解耦的核心架构思路，同时又借鉴传统的微服务架构框架，基于传统方法来开发能够提供核心业务服务能力的业务组件。

　　这个业务组件你完全可以采用传统的开发语言，开发方式进行开发。但是开发完成后仍然需要融合到整个云原生和微服务架构体系里面去。也正是整个原因，我们完全可以理解为Dapr是微服务，服务网关，无服务器化三者核心思想的一个融合，这也正是整个云原生下微服务框架发展的趋势。

　　大家可以参考下图进行理解：

　　简单来讲就是开发人员只需要关心BaaS层业务组件微服务的开发，其它和底层资源和技术服务的集成和适配，API接口的能力开放，微服务组件之间的交互，微服务本身的服务治理和可观测性问题全部由Dapr框架来完成。

　　Dapr框架实际是融合了ServiceMesh服务网关和ServerLess无服务器化两者的核心思想，真正实现了让开发人员从技术基础设施和底层资源逻辑，服务治理管控中脱离出来。

　　Dapr符合云原生和微服务发展演进趋势

　　在我前面谈云原生和DevOps的文章中谈到，希望基于DevOps持续集成和交付能力来构建一个多云适配的能力平台。即你在私有云环境中开发完成的应用，能够灵活的朝不同的公有云服务商进行交付，也能够灵活的在多个公有云之间进行迁移。

　　当我在谈这个问题的时候，实际重点仍然是基于公有云服务的资源层虚拟机或者基于公有云提供的标准Kurbernetes API接口层对接容器能力。

　　但是对于核心的PaaS层数据库，消息中间件，缓存，日志等各种技术服务能力并无法支撑。也就是说如果你用的阿里云的RocketMQ消息中间件，你如何迁移到华为云？或者即使你用的阿里云的Mysql数据库即服务能力？你如何保证一定可以平滑迁移到华为云的Mysql数据库服务上面去？

　　因此，这种和公有云的适配不是简单的资源层包括容器层的适配，更加重要的是各种技术服务能力的适配，这些技术服务能力可以理解为ServerLess无服务器架构中的BaaS层能力。

　　这种适配在哪里做？

　　按Dapr的思路，我们可以在Components组件层来完成这种适配工作。

　　当开发人员在开发新的应用的时候，只需要使用Dapr架构框架下的数据库，消息等API接口能力，同时又确保你开发的应用能够平滑的向云端的云原生架构进行快速交付。也不会被某个单一的云服务商强制绑定。

　　包括我在前面谈ServerLess架构演进的时候也谈到，简单的BaaS+FaaS无法支撑复杂的企业级应用开发，对于企业级应用核心仍然是业务BaaS层的开发，并将能力通过API接口方式暴露给前端应用。

　　但是业务BaaS层业务组件和服务的开发同样需要使用类似消息，缓存等各种技术BaaS层服务能力，技术BaaS+业务BaaS才构成完成的底层服务层能力提供。

　　因此我们需要找到一种方式或架构框架，同时满足对业务BaaS微服务的开发定制，从资源到服务层能力的抽象和适配，通过边车模式实现的微服务治理管控，基于API接口服务实现的前后端分层和能力解耦。

　　而对于Dapr框架本身具备上述大部分能力，这也是我们将Dapr架构和框架实现思路是后续云原生和微服务架构发现的关键趋势的原因。