Microsoft DevOps 文档里的文章(https://docs.microsoft.com/zh-cn/azure/devops/report/dashboards/cycle-time-and-lead-time?view=azure-devops)中的这张图片在给我们介绍了 什么是周期时间 以及它如何影响我的项目流时非常有影响力。
第一次输入 "正在进行" 或 "已解决" 状态类别到输入 "已完成" 状态类别,计算周期时间。 当开发人员编写代码时,能够快速验证更改并进行修订对于保持较短的周期时间至关重要。
丰田生产方式之父大野耐一曾经说过:我们唯一要做的就是降低从接到订单到交付产品给客户的周期时间。周期时间的降低可以有效保证软件的按时交付 。所以周期时间是软件交付的核心目标。
特别是微服务的设计和开发,通常需要达成下列4个目标:
我们借助于Dapr 可以非常容易的达成以上4个目标, 使用 Docker Compose 和 Dapr 技巧进行本地开发,测试和生产环境运行于Kubernetes, Kubernetes现在是各大云厂的标配服务。借助于Dapr 的语言无关性,平台无关性,我们可以在环境上尽量的缩短了时间,保持较短的周期时间交付软件。
我们可以在大脑里面来回顾一下我们的开发过程,对于每个任务/代码更改:
只有当开发人员脱离这个循环时,他们才能将他们的代码签入主程序。这个过程太疯狂了!仅第 4 步在镜像创建和部署之间就花费了大约 20 分钟。两三个遗漏的错误可能会使开发人员在一天中花掉大约1个小时,并且考虑到除了日常工作之外,我们都在从事这项工作,这扼杀了生产力。还有可能要考虑到部署对依赖项的更改所需的周期,此处的部署花费了更长的时间。
下面我们从 提高软件开发生产力角度来聊聊,Dapr所提供的主要生产力提高优势是:
将分布式系统的服务彼此分离,可以使软件开发、扩展和维护软件更具时间和成本效益,也更容易。为什么?将软件片段彼此分离可以使其内部代码内容和代码结构彼此独立地变化,从而大大减少了需求更改时代码更改所需的工作量。这种脱钩是减少技术债务的最佳方法之一,并随着岁月的流逝保持低水平,从而从长远来看提高生产率。
Dapr 产生解耦的一个关键方式是通过其构建块,每个构建块都定义了分布式系统常用功能的概念接口。对于大多数构建块,Dapr 还提供了许多预构建的插件组件,每个组件都为构建块概念的特定实例实现构建块接口的全部或部分。使用预构建的插件组件还可以减少所需的编码工作量。如果没有 Dapr,开发人员不知道有多少次必须一遍又一遍地编写大致相同的低级管道代码,才能连接到我们的代码使用的每个数据库或云服务并与之交互?使用Dapr的构建块/组件方法,答案为零!使用预构建的插件组件可节省大量时间,使开发人员能够专注于更高价值的工作。
如果我告诉你,Dapr是一个用于分布式系统的瑞士军刀实用程序服务,你很可能会想发现Dapr的许多功能,因为它既是中介又是解耦者。Dapr 提供的主要功能如下,其中许多功能通过构建块和组件实现,但不是全部:
请注意,上述所有预构建的插件组件也是可配置的。"插入"特定组件的行为只是在标准组件目录中提供声明性配置文件。Dapr 负责加载组件代码和"挂接"所需的工作。
如果我告诉你Dapr是一个Sidecar,你就会知道,通常Dapr的单个实例与服务的单个实例配对,每个实例都在自己的进程中运行。Dapr 目前不是代码库。Dapr Sidecar 实例和使用它的服务实例通过 HTTP 或 gRPC(使用 HTTP2)跨其进程边界相互通信,如下图 所示。当您将服务实例与 Dapr Sidecar 配对时,您实质上是"Daprize"您的服务。
此外,每个 Dapr Sidecar 实例都知道协作"Daprized"服务系统中的所有其他 Dapr Sidecar 实例。所有这些协作 Dapr Sidecar 实例都使用 gRPC 在单独的 Sidecar 专用通信通道上完全在后台相互通信,如下图所示。以这种方式在Dapr Sidecars之间进行通信是Dapr的Pub / Sub,服务调用和Actor模型功能的关键。Dapr Sidecar 和使用 Dapr Sidecar 实例的服务通常在单独的容器中运行,或作为单独的独立进程运行。
"Daprized"服务通常只与其单个私有 Dapr Sidecar 交互,如上图 所示,将所有凌乱的管道细节以及如何与其他服务、存储、机密等通信的知识留给 Dapr Sidecar 本身,以及 Dapr Sidecar 实例中使用的 Dapr 组件。这使得服务代码变得不那么复杂,并且在服务中的业务逻辑代码与 Dapr Sidecar 及其组件中的管道逻辑代码(也称为基础结构代码)之间提供了很好的关注点分离。在上面的图 中,黄色服务包含所有业务逻辑,而粉红色的 Dapr Sidecar 包含大部分(如果不是全部)管道代码。业务逻辑代码和管道逻辑代码之间的这种关注点分离是使用Dapr导致的技术债务显着减少的关键之一。因此,当需求不可避免地发生变化时,通常需要更改的代码比管道代码与业务逻辑代码混合和交织的情况要少得多。
最后,在业务逻辑和管道代码之间实现高度的关注点分离,再加上组件,开发人员将更多的时间集中在高价值的业务逻辑上,而将更少的时间集中在低价值的组件管道代码上。虽然低级管道规范是绝对必要的,但开发低级管道规范既复杂又耗时,并且需要高水平的经验 - 所有这些都需要时间和金钱。相反,使用预构建的"插件"组件可以将开发人员的大部分时间和技能重新定向到开发业务逻辑上,从而产生与软件最终用户最直接相关的价值。
现在可以看到Dapr Sidecar(加上它使用的组件)如何站在使用Sidecar的服务和分布式系统中的所有其他服务之间,以及"Daprized"服务可以连接到的所有可能的云服务或本地服务之间。这可能是很多服务!因此,在理解"Daperized"服务的以下3个主要使用场景时,Dapr作为中介的角色至关重要。
另请注意,"Daprized"服务可以托管在Kubernetes上的容器中,也可以托管在支持Docker等容器的其他主机上,包括在适当的情况下使用Docker Compose。"Daprized"服务也可以托管,而无需在各种计算主机(包括您自己的开发系统)上使用容器作为独立进程。
纵观软件的历史,Dapr的潜在节省时间和劳动力的特点真的是一件大事!到目前为止,还没有像Dapr这样的东西,它几乎可以在任何地方运行,并且还提供了与分布式系统服务的大规模解耦,以及组件化和出色的关注点分离。所有这些都减少了初始开发所需的工作,并且从长远来看,还导致技术债务明显低于平时。从短期和长期来看,所有这些都可以显著提高软件开发生产力,从而减少需要完成的工作量,节省时间和金钱。