正文 

当前位置： 首页 > 代码 > java教程

《云原生入门级开发者认证》学习笔记之云原生基础设施之容器技术(代码片段)

山河已无恙 山河已无恙     2022-12-04     594

关键词：

写在前面

  • 嗯，报了考试，整理课堂笔记记忆
  • 学习的原因：
    • 虽然考了CKA,了解了一些K8s相关的知识
    • 但是对云原生整个体系一直都很模糊
    • 希望对云原生有一个基本的认识
    • 通过学习实现云原生相关入门
  • 博文主要内容涉及：
    • 关于Docker知识体系的简述，适合温习
    • 讲的很浅，都是理论，没有实战

傍晚时分，你坐在屋檐下，看着天慢慢地黑下去，心里寂寞而凄凉，感到自己的生命被剥夺了。当时我是个年轻人，但我害怕这样生活下去，衰老下去。在我看来，这是比死亡更可怕的事。--------王小波

云原生基础设施之容器技术

容器发展背景

企业IT业务云化路径

传统业务云化

业务云化创新

容器是什么?

容器是一种轻量级、可移植、自包含的软件打包技术,使应用程序可以在几乎任何地方以相同的方式运行。

开发人员在自己开发环境创建并测试好的容器,无需任何修改就能够在生产系统的虚拟机、物理服务器或公有云主机上运行

容器核心思想

将集装箱的思想应用到了软件的打包和部署上，为各类不同的代码提供了一个基于容器的标准化运输系统。

容器与虚拟机

容器和虚拟机 之间的主要区别在于虚拟化层的位置和操作系统资源的使用方式。

用户运行在容器里的应用进程,跟宿主机上的其他进程一样,都由宿主机操作系统统一管理,只不过这些被隔离的进程拥有额外设置过的Namespace参数。而Docker项目在这里扮演的角色,更,多的是旁路式的辅助和管理工作

Docker项目介绍

2013年, dotCloud公司将Docker项目开源。
Docker项目:GitHub上开发的Moby开源项目的一部分，遵循Apache License 2.0许可证协议，Go语言编写Docker是一个开源的引擎,可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。

Docker公司目前推出两个版本:

  • Docker CE (社区版)，
  • Docker EE (企业版)

容器关键技术介绍

容器规范

容器不光是Docker,还有其他容器,比如CoreOS的rkt,红帽的podman，以及之后的K8s之后的containerd。为了保证容器生态的健康发展,保证不同容器之间能够兼容,包含Docker-CoreOS-Google在内的若干公司共同成立了一个叫Open Container Initiative(OCI)的组织,其目是制定开放的容器规范。

容器runtime

runtime与操作系统kernel紧密协作,为容器提供运行环境。常见的容器runtime:

  • runC是Docker公司2015年发布的容器runtime工具,符合OCI规范。 runC Libcontainer演变而来。
  • rkt,是CoreOS公司开发的Docker/runc的一个流行替代方案,符合OCI规范。
  • Kata, 2017年整合Clear ContainerNrunV项目,基于虚拟化技术的容器实现,符合OCI规范。
  • gVisor ,2018 年Google公司发布 gVisor的项目,基于虚拟化技术的容器实现,符合OCI规范

Docker 引擎

Docker主要指容器引擎,即Docker engine。Docker Engine是-个Client/Server应用程序。Docker engine主要组件有3部分:

  • 服务器:是一个长期运行的程序,称为daemon进程:Docker daemon用于创建和管理docker对象,如容器镜像、容器、网络、卷。
  • 命令行界面客户端(docker CLI):CLI使用Docker REST API通过脚本或直接的CLI命令与Docker daemon交互。
  • 一个REST API:Client可以用它来与daemon进程通信交互。

Docker 架构

  • Docker Client: Docker是个采用的C/S架构的应用程序。Docker Client一般通过Docker command来发起请求。在用户界面,支持用户与Docker Daemon之间通信
  • Docker daemon :简单地说, Docker daemon实现的功能就是接收客户端发来的请求,并实现请求所要求的功能,同时针对请求返回相应的结果。Docker daemon是驱动整个Docker功能的核心引擎。在功能的实现上,Docker daemon涉及了容器、镜像、存储等多方面的内容,涉及多个模块的实现和交互。
  • Containers :容器以镜像为基础,同时又为镜像提供了一个标准和隔离的运行环境。Docker的容器就是“软件界的集装箱”,可以安装任意的软件和库文件,做任意的运行环境配置。开发及运维人员在转移和部署应用的时候,不需关心容器里装了什么软件,也不需了解它们是如何配置的。
  • Docker Image :与容器相对应,如果说容器提供了一个完整的、隔离的运行环境,那么镜像则是这个运行环境的静态体现
  • Registry : Registry是一个存放镜像的仓库。Registry本身也是一个单独的开源项目企业可使用Registry镜像搭建私有仓库。

Docker容器实现原理

Docker容器通过namespace技术实现进程隔离,通过cgroup技术实现容器进程可用资源的限制。Docker启动一个容器时,实际是创建了包含多个namespace参数的进程。

Namespace

Namespace :命名空间作用:资源隔离。 namespace将内核的全局资源进行封装,使得每个namespace都有一份独立的资源。因此不同进程在各自namespace内对同一种资源的使用不会相互干扰。


Namespace实际上是Linux系统上创建新进程时的一个可选参数。实际上在创建Docker容器时,指定了这个进程所需要启用的一组namespace参数。通过namespace机制的隔离,容器只能见到当前Namespace中所限定的资源、文件、设备、状态或配置。以此实现应用运行环境的隔离。

PID namespace隔离示例

以交互模式启动一个centos容器,并在其中运行/bin/bash程序。执行ps命令查看到"/bin/bash"是PID=1的进程,即Docker将其隔离于宿主机中的其他进程之外。

Cgroups

Cgroups : Linux Control Groups作用:限制一个进程组对系统资源的使用上限,包括CPU、内存、Block I/O等。

┌──[root@vms81.liruilongs.github.io]-[~]
└─$cd /sys/fs/cgroup
┌──[root@vms81.liruilongs.github.io]-[/sys/fs/cgroup]
└─$ls
blkio  cpuacct      cpuset   freezer  memory   net_cls,net_prio  perf_event  systemd
cpu    cpu,cpuacct  devices  hugetlb  net_cls  net_prio          pids
┌──[root@vms81.liruilongs.github.io]-[/sys/fs/cgroup]
└─$

Cgroups还可以设置进程优先级,对进程进行挂起和恢复等操作。

原理 :将一组进程放在一个Cgroup中,通过给这个Cgroup分配指定的可用资源,达到控制这一组进程可用资源的目的

实现 :在Linux中,Cgroups以文件和目录的方式组织在操作系统的/sys/fs/cgroup路径下。该路径中所有的资源种类均可被Cgroup限制。

┌──[root@vms81.liruilongs.github.io]-[/sys/fs/cgroup]
└─$mount -t cgroup
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
┌──[root@vms81.liruilongs.github.io]-[/sys/fs/cgroup]
└─$

容器镜像

对软件开发而言，容器镜像打通了“开发 - 测试 - 部署”的流程。

镜像是容器的模板,容器是镜像的运行实例,runtime根据镜像创建容器

容器镜像挂载在容器根目录下,为容器中的应用提供执行环境的文件系:容器镜像打包了整个操作系统的文件和目录(rootfs),也包括应用本身,即应用及其运行所需的所有依赖都被封装在容器镜像中。

容器镜像采用分层结构:所有容器共享宿主机Kernel,并且不能修改宿主机Kernel ·即容器运行过程中使用容器镜像中的文件,使用宿主机OS上的Kermel

  • Build any Application：根据image format spec标准，任何应用都可以被制作成容器镜像，
  • Ship any Anywhere：根据runtime spec标准，容器镜像可以传送到任何环境中运行。

容器镜像只是提供了一套镜像文件系统中的各种文件,而各种内核相关的模块或者特性支持,完全依赖于宿主机。

UnionFS联合文件系统

Docker镜像分层结构的实现，借助于UnionFS联合文件系统的能力.

Union File System联合文件系统,是实现Docker镜像的技术基础。它是一种轻量级的高性能分层文件系统,支持将文件系统中的修改进行提交和层层叠加。这个特性使得镜像可通过分层实现和继承。同时支持将不同目录挂载到同一个虚拟文件系统下。

以Overlay2为例: Overlay2是一种堆叠文件系统,它依赖并建立在其它的文件系统之上(如ext4fs、xfs等),并不直接参与磁盘空间结构的划分,仅将原来底层文件系统中不同的目录进行“合并”,然后向用户呈现,这也就是联合挂载技术。

嗯，这里不太理解，感觉整理类似是linux中的LVM，局部类似写时复制技术，基础的镜像文件不会被修改，只是对修改进行记录，在写入的时候，对镜像文件写入部分进行复制，然后修改后记录。看到的是基础镜像文件 + 写时复制的记录的叠加。

容器数据卷

卷就是目录或文件,存在于一个或多个容器中,由docker挂载到容器,但不属于联合文件系统,因此能够绕过Union File System提供一些用于持续存储或共享数据的特性。

将运用与运行的环境打包形成容器运行,对数据的要求希望是持久化的。
容器之间希望有可能共享数据。

卷的设计目的就是数据的持久化,完全独立于容器的生存周期,因此Docker不会在容器删除时删除其挂载的数据卷。

  • 启动容器的时候直接使用-v命令就可以进行数据卷的挂载。
  • 还可以在Dockerfile中使用VOLUME指令来给镜像添加一个或多个数据卷,

容器copy-on-write特性

对容器的增删改查：

  • 创建文件:新文件只能被添加在容器层中。
  • 删除文件:依据容器分层结构由上往下依次查找。找到后,在容器层中记录该删除操作。具体删除文件实现是:UnionFS会在容器层创建一个"whiteout"文件,将被删除的文件“遮挡”起来。
  • 修改文件:依据容器分层结构由上往下依次查找。找到后,将镜像层中的数据复制到容器层进行修改,修改后的数据保存在容器层中(copy-on-write)。
  • 读取文件:依据容器分层结构由上往下依次查找,

所有storage driver都支持镜像分层结构和写时复制(CoW)策略。

Registry

Registry是存放容器镜像的仓库,用户可进行镜像下载和访问,分为公有和私有两类Registry。

公有镜像仓库:

  • Docker Hub是Docker公司为公众提供的托管Registry。
  • Quay.io现为Red Hat下的公共托管Registryo

私有镜像仓库:

  • 企业可以用Docker Registry构建私有的Registry。Registry本身是一个开源项目,可以用于搭建私有Registry

Docker Hub中可查看到Registry镜像的Dockerfile。

Docker Hub

Docker Hub是目前世界上最大的容器镜像仓库,由Docker公司维护,并提供官方镜像及大量用户上传的镜像。

如何使用Dockerfile构建镜像

Dockerfile是一个文本文件,其内包含了一条条的指令,每一条指令构建一层,因此每一条指令的内容,就是描述该层应当如何构建。所以为了减少存储占用，一般尽可能把run指令写到一行。

Docker提供了两种构建镜像的方法：docker commit命令与dockerfile构建文件。

Dockerfile

Dockerfile :文件指令集,描述如何自动创建Docker镜像。

  • Dockerfile是包含若干指令的文本文件,可以通过这些指令创建出docker image。
  • Dockerfile文件中的指令执行后,会创建一个个新的镜像层。
  • Dockerfile文件中的注释以"#"开始。
  • Dockerfile一般由4部分组成:
    • 基础镜像信息.
    • 维护者信息
    • 镜像操作指令
    • 容器启动指令
  • build context :为镜像构建提供所需的文件或目录。
描述指令
指定base镜像FROM
注明镜像的作者MAINTAINED
运行指定的命令RUN
将文件从build context复制到镜像中ADD
将文件从build context复制到镜像中(自动解压)COPY
设置环境变量ENV
指定容器中的应用监听的端口EXPOSE
设置后动容器的用户USER
设置在容器启动时运行指定的脚本或命令CMD
指定的是一个可执行的脚本或者程序的路径ENTRYPONT
将文件或目录声明为volume，挂载到容器中VOLUME
设置镜像的当前工作目录WORKDIR

Dockerfile的指令根据作用可以分为两种：

  • 构建指令：构建指令用于构建image，其指定的操作不会在运行image的容器上
    执行。
  • 设置指令：设置指令用于设置image的属性，其指定的操作将在运行image的容器中执行。

Dockerfile指令使用注意事项：

  • RUN等指令后运行的必须是基础image支持的命令。如基础image选择了centos，那么软件管理部分只能使用centos的命令。
  • ADD指令与COPY指令的不同在于，在ADD指令中，若src是压缩文件，则会自动解压到dest。
  • Dockerfile中若有多条CMD命令，则只执行最后一条。
  • Dockerfile中若有多条ENTRYPOINT命令，则只执行最后一条。
  • CMD与ENTRYPOINT的不同在于：当Docker run command的命令匹配到CMD command时，会替换CMD执行的命令。ENTRYPOINT指令提供的命令则不容易在启动容器时被覆盖。实际上, docker run命令行中指定的任何参数都会被当做参数再次传递给ENTRYPOINT指令中指定的命令。

使用ENTYRPOINT

#ENTRYPOINT [ "/usr/sbin/nginx", "-g" , "daemon off;" ] 
ENTRYPOINT [ "usr/sbin/nginx" ]
sudo docker run -it nginx -g "daemon off;"

同时使用ENTRYPOINT和CMD

ENTRYPOINT [ "/usr/sbin/nginx" ]
CMD [ "-h" ]
#  /usr/sbin/nginx  -h  显示帮助信息

如果确实需要,用户也可以在运行时通过docker run的--entrypoint标志覆盖ENTRYPOINT指令

一个简单的Dockerfile

#基于centos镜像
FROM centos
#维护人的信息
MAINTAINER docker_user docker_user@email.com
#安装httpd软件包
RUN yum-y update  && RUN yum-y install httpd
#开后80端口
EXPOSE 80
#复制网站首页文件至镜像中web站点下
ADD index.html /var/www/html/index.html
#复制该脚本至镜像中·并修改其权限
ADD run.sh /run.sh
RUN chmod 775 /run.sh
#当后动容器时执行的脚本文件
CMD[/run.sh"]

容器生命周期管理

查看Docker服务状态

┌──[root@vms81.liruilongs.github.io]-[/]
└─$systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since 日 2022-04-03 18:43:45 CST; 18h ago
     Docs: https://docs.docker.com
 Main PID: 1120 (dockerd)
   Memory: 157.7M
   CGroup: /system.slice/docker.service
           └─1120 /usr/bin/dockerd --insecure-registry 192.168.26.56 -H fd:// --containerd=/run/containerd/containerd...

4月 03 18:44:51 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-03T18:44:51.153876648+08:00" level=info ...ete"
4月 04 08:07:05 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-04T08:07:05.336006734+08:00" level=error...ifo"
4月 04 08:07:05 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-04T08:07:05.396998780+08:00" level=error...ifo"
4月 04 08:07:05 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-04T08:07:05.406139699+08:00" level=error...own"
4月 04 08:07:06 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-04T08:07:06.332774038+08:00" level=info ...ete"
4月 04 08:07:06 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-04T08:07:06.336614138+08:00" level=error...ifo"
4月 04 08:07:06 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-04T08:07:06.353399388+08:00" level=error...ifo"
4月 04 08:07:06 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-04T08:07:06.384605677+08:00" level=info ...rce"
4月 04 08:07:06 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-04T08:07:06.600509732+08:00" level=error...own"
4月 04 08:07:07 vms81.liruilongs.github.io dockerd[1120]: time="2022-04-04T08:07:07.067233807+08:00" level=info ...ete"
Hint: Some lines were ellipsized, use -l to show in full.
┌──[root@vms81.liruilongs.github.io]-[/]
└─$

容器生命周期管理

容器生命周期管理命令：

  • docker create：创建一个容器；
  • docker start：启动一个容器；
  • docker run：创建并运行一个容器；
  • docker pause：暂停一个容器；
  • docker unpause：恢复一个容器；
  • docker restart：重启一个容器；
  • docker stop：停止一个运行的容器；
  • docker rm：删除一个处于终止状态的容器；
  • docker kill：杀死容器进程

进入一个容器

docker attach命令：

  • docker attach命令直接进入已启动容器的命令终端，不会启动新的进程。
  • Usage：docker attach [OPTIONS] CONTAINER

docker exec命令：

  • docker exec命令是在容器中打开新的终端。
  • Usage：docker exec [OPTIONS] CONTAINER COMMAND [ARG…]

其他常见命令

  • 使用docker inspect获取容器/镜像元数据。
  • 使用docker tovp命令查看容器中运行的进程信息。
  • 使用docker events从服务器获取实时事件。
  • 使用docker port列出指定的容器的端口映射。

《云原生入门级开发者认证》学习笔记之云原生架构总览(代码片段)

写在前面嗯，报了华为云的一个《云原生入门级开发者认证》，这里整理课堂笔记记忆，感兴趣小伙伴也可去试试学习的原因：虽然考了CKA,了解了一些K8s相关的知识，但是对云原生一直都很模糊希望对云原生... 查看详情

《云原生入门级开发者认证》学习笔记之云原生架构总览(代码片段)

写在前面嗯，报了华为云的一个《云原生入门级开发者认证》，这里整理课堂笔记记忆，感兴趣小伙伴也可去试试学习的原因：虽然考了CKA,了解了一些K8s相关的知识，但是对云原生一直都很模糊希望对云原生... 查看详情

《云原生入门级开发者认证》学习笔记之微服务架构介绍(代码片段)

写在前面嗯，学习云原生相关，整理课堂笔记记忆学习的原因：虽然考了CKA,了解了一些K8s相关的知识但是对云原生整个体系一直都很模糊作为Java开发来讲，微服务是大多数行业都要涉及的开源技术栈博文主要内... 查看详情

云原生应用开发，通过一个案例手把手带你入门

...制避免超常负载,保障系统高可用。提升运维效率。采用基础设施即服务模式,利用其预构建的资源抽象来简化底层基础设施的部署和管理。实现自动化部署和流畅的上线rollback等。适应前后端分离和微服务化发展。通过前后端分... 查看详情

亚马逊云科技——云原生主题容器入门笔记

嗨，大家好，我是异星球的小怪同志一个想法有点乱七八糟的小怪如果觉得对你有帮助，请支持一波。希望未来可以一起学习交流。 目录一、容器入门课程二、容器入门课堂笔记1.容器背后的发展历史2.区分容器与逻... 查看详情

一文搞定完整的云原生边缘基础设施堆栈(代码片段)

作者简介JanakiramMSV是Janakiram&Associates的首席分析师，也是国际信息技术学院的兼职教师。他也是GoogleQualifiedDeveloper、亚马逊认证解决方案架构师、亚马逊认证开发者、亚马逊认证SysOps管理员和微软认证Azure专业人员。Janakira... 查看详情

如何基于k3s构建云原生边缘基础设施？

作者简介JanakiramMSV是Janakiram&Associates的首席分析师，也是国际信息技术学院的兼职教师。他也是GoogleQualifiedDeveloper、亚马逊认证解决方案架构师、亚马逊认证开发者、亚马逊认证SysOps管理员和微软认证Azure专业人员。Janakira... 查看详情

阿里云刘伟光：2万字解读金融级云原生

...展从狭义到广义，今天的云已经变成了更为普适性的标准基础设施，更是新技术新业务创新的平台；因此诸如云原生大数据，和云原生存储以及云原生网络技术等技术让云的原生能力从软 查看详情

云原生设备云之云服务器的配置与使用

文章目录一、配置云服务1、创建连接设备2、配置云服务参数3、调试云服务二、云服务的使用1、发布主题2、实时数据3、发布状态或信息4、发布的信息列表5、发布的主题列表6、订阅主题7、Topiclist8、Pause9、MDataPubCycle一、配置云... 查看详情

一文搞定完整的云原生边缘基础设施堆栈(代码片段)

...f0c;该集群是一组运行Ubuntu18.04的英特尔NUC迷你电脑。这种基础设施可用于在边缘运行可靠、可扩展和安全的AI和IoT工作负载。为Calico自定义K3s安装默认情况下，K3s使用Flannel作为容器网络接口（CNI）运行，使用VXLAN... 查看详情

如何基于k3s构建云原生边缘基础设施？

...成为在混合云和多云环境中运行工作负载的一致和统一的基础设施层。物联网和人工智能的兴起，促使业界在将计算能力向数据靠拢，这就成为边缘计算层。边缘计算是边缘设备和云端/数据中心的中介。它基于业务逻辑... 查看详情

云原生springcloud微服务学习路线汇总

...用的SpringBoot框架开发便利性、巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以利用SpringBoot的开发风格做到一键启动和部署。SpringCloud没有重复... 查看详情

入门云原生，你需要了解的基础知识

...，以及网上银行促进创新以满足日益增长的客户需求，云原生技术在其中发挥重要作用，同时也加速了云原生的普及。什么是云原生？云原生是一种基于容器、微服务和自动化运维的软件开发和部署方法。它可以使应用程序更加... 查看详情

容器云原生devops学习笔记——第一期：devops微服务容器服务(代码片段)

...一直懵懵懂懂，最近观看了阿里专家带你玩转容器云原生DevOps公开课开始系统的学习DevOps，所以根据学习视频整理出以下学习笔记希望分享给更多对此感兴趣的同学～课程大纲如下图所示，会陆续进行更新：De... 查看详情

1.kong入门与实战基于nginx和openresty的云原生微服务网关---基础知识点概述(代码片段)

1.1　网关　 网关是一种高性能，低延迟的流量负载均衡服务，是大型分布式系统中用来保护内部服务的一道安全屏障。它可以对请求实施统一拦截，帮助开发人员轻松的向外界提供服务，是的开发人员不必考虑路... 查看详情

不看后悔，一文入门go云原生微服务(代码片段)

...1.先启动服务端2.再启动客户端总结关于专栏一起学习Go云原生开发有着天然的优势，云原生系统需要可扩展、耦合、弹性可管理。Go微服务框架很多，包括：go-micro、go-zero、go-kit、go-kratos、tars-go、dubbo-go、jupiter等等…... 查看详情

不看后悔，一文入门go云原生微服务(代码片段)

...1.先启动服务端2.再启动客户端总结关于专栏一起学习Go云原生开发有着天然的优势，云原生系统需要可扩展、耦合、弹性可管理。Go微服务框架很多，包括：go-micro、go-zero、go-kit、go-kratos、tars-go、dubbo-go、jupiter等等…... 查看详情

.net云原生架构师训练营（基于opstorming和actor的大型分布式架构三）--学习笔记...

▲ 点击上方“DotNetNB”关注公众号回复“1”获取开发者路线图学习分享 丨作者 / 郑 子 铭    这是DotNet NB 公众号的第204篇原创文章目录为什么我们用OrleansDaprVSOrleansActor模型Orleans的核心概念结合OPStorming的实践结合OPStormin... 查看详情