文章目录

前言
一、Istio的基本概念
- 1.Istio诞生背景
- 2.Istio的定义
- 3.Istio优势
二、Istio整体架构及工作原理
- 1.Istio整体架构
- - 1.1 控制面Istiod
  - - 1.1.1 Pilot
    - 1.1.2 Citadel
    - 1.1.3 Galley
    - 1.1.4 Sidecar-lnjector
  - 1.2 数据面
  - - 1.2.1 Envoy
    - 1.2.2 Pilot-Agent
三、lstio无侵入的Sidecar基本原理
- 1.Sidecar基本介绍
- 2.Sidecar流量拦截
- - 2.1 Sidecar流量拦截完整流程
- 3.Envoy基本介绍
- - 3.1 Envoy相关组件
- 4.Envoy流量代理流程
- 5.Envoy流量匹配与转发
- - 5.1 Envoy流量匹配与转发完整流程
四、Istio服务网格基本功能实现原理
- 1.流量治理基本API
- 2.流量治理基本原理
- - 2.1 Istio流量治理的基本流程
- 3.服务发现
- - 3.1 Istio服务发现的基本流程
- 4.路由匹配
- 5.灰度发布
- - 5.1 灰度发布的基本流程
- 6.服务网格监控-Observability
- - 6.1 服务网格监控-Metrics
  - 6.2 服务网格监控-Trace
  - 6.3 服务网格监控-AccessLog
总结

前言

本文主要介绍的内容有：

Istio的基本概念
Istio整体架构及工作原理
lstio无侵入的Sidecar基本原理
Istio服务网格基本功能实现原理

一、Istio的基本概念

1.Istio诞生背景

Istio是一个由谷歌、IBM与Lyft共同开发的开源项目，旨在提供一种统一化的微服务连接、安全保障、管理与监控方式。Istio项目能够为微服务架构提供流量管理机制，同时亦为其它的需求功能（包括安全性、监控、路由、连接管理与策略等）创造了基础。这款软件利用久经考验的Lyft Envoy代理进行构建，可在无需对应用程序代码作出任何发动的前提下实现可视性与控制能力。Istio项目是一款强大的工具，可帮助CTO/CIO等企业管理者，立足于企业内部实施整体性安全、政策与合规性的要求。

2.Istio的定义

Istio提供一种简单的方式来建立已部署的服务的网络，具备负载均衡，服务到服务认证，监控等等功能，而不需要改动任何服务代码。简单的说，有了Istio，你的服务就不再需要任何微服务开发框架，也不再需要自己手动实现各种复杂的服务治理功能。只要服务的客户端和服务端可以进行简单的直接网络访问，就可以通过将网络层委托Istio，从而获得一系列的完备功能。可以近似的理解为：

Istio = 微服务框架 + 服务治理

3.Istio优势

Istio的优势	说明
集群规模可视性	在故障状况出现时，运营人员需要利用多种工具以始终关注集群运行状况并分析微服务状态图表。Istio项目能够监控与应用程序及网络活动相关的数据，利用Prometheus与Grafana对这部分数据加以渲染，而后将相关指标与日志记录发送至任何收集、聚合与查询系统当中以实现功能扩展。Istio项目亦利用Zipkin追踪分析性能热点并对分布式故障模式加以诊断。
弹性与效率	在开发微服务时，运营人员需要假设网络本身处于不可靠状态。运营人员能够利用重试、负载均衡、流量控制（HTTP/2）以及断路补偿等方式解决由网络可靠性低下所造成的各类常见故障模式。Istio项目则提供一种统一方法以配置上述功能，使得运营人员能够更为轻松地运作高弹性水平服务网格。
开发人员生产力	Istio项目能够确保开发人员专注于利用已选择的编程语言构建服务功能，从而极大提升其生产能力。另外，Istio项目则负责以统一化方式处理弹性与网络挑战。开发人员无需将解决方案的分布式系统问题解决机制引入编写的代码当中。Istio项目还能够支持A/B测试、金丝雀部署以及故障注入等常用功能，旨在进一步提高生产效率。
政策驱动型运营	Istio项目能够授权具有不同职能的团队以实现独立运作。其将集群运营人员与功能开发人员进行周期性剥离，从而在无需更改代码的前提下提升安全性、监控能力、扩展性与服务拓扑水平。运营人员能够精确控制生产流量中各个子集的路由方式，从而匹配新的服务版本。另外，运营人员还能够在流量中注入故障或者提高延迟水平，用来测试服务的弹性，同时设置速率限制以防止服务过载。Istio项目还可用于强制执行合规性要求，例如在服务之间定义CL以确保仅具备授权的服务间可相互通信。
默认安全	分布式计算当中经常存在着大量网络安全问题。Istio项目允许运营人员利用TLS连接来认证并保护各服务之间的所有通信，而不会给开发人员或者运营人员带来由证书管理造成的额外负担。其安全框架与新的SPIFFE规范保持一致，事实上谷歌公司一直在内部广泛使用类似的保障性系统。
增量化采用	在设计Istio项目时充分考虑到网络内所运行各服务的透明性，允许团队随着时间推移逐步采用Istio提供的各项功能。采用方可以先从启用集群范围内可视性起步，并在Istio在环境中的表现感到满意后根据实际需要启用其它功能。

二、Istio整体架构及工作原理

1.Istio整体架构

Istio架构分层来看主要分为

控制面Istiod(Pilot、Citadel、Galley、Sidecar-lnjector)

控制平面管理并配置代理来进行流量路由。此外，控制平面配置 Mixer 来执行策略和收集遥测数据。
数据面(Envoy、Pilot-Agent)

数据平面由一组智能代理（Envoy）组成，被部署为 sidecar。这些代理通过一个通用的策略和遥测中心（Mixer）传递和控制微服务之间的所有网络通信。

1.1 控制面Istiod

控制面主要分为以下4部分：

Pilot:xDS服务器，为数据面代理提供各种配置
Citadel:为数据面签发证书
Galley:Admission Webhook，校验Istio API配置
Sidecar-lnjector:自动注入Sidecar

1.1.1 Pilot

Pilot基本架构：

原生支持Kubernetes，List-Watch Service，Endpoint，Pod，Node，etc
扩展支持其他注册中心，以MCP协议的方式
xDS服务器向下对所有的数据面Sidecar提供xDS配置
中间内核层负责生成xDS配置，每一种xDS对应有一种生成器，xDS Generator深入理解Istio API与Envoy API之间的转换

服务列表中的istio-pilot是istio的控制中枢Pilot服务。如果把数据面的envoy也看作一种agent，则Pilot类似传统C/S架构中的服务端Master，下发指令控制客户端完成业务功能。和传统的微服务架构对比，Pilot至少涵盖服务注册中心和Config Server等管理组件的功能。pilot可以直接从kubernetes，consul提取数据并将其构造和转换成istio的服务发现模型，因此pilot只有服务发现功能，无须进行服务注册。这种抽象模型解耦Pilot和底层平台的不同实现，可支持kubernetes，consul等平台

1.1.2 Citadel

Citadel基本架构：

Citadel是服务网格的安全组件与NodeAgent一起为工作复杂提供证书的签发、轮换。
Citadel对下处理来自NodeAgent的CSR请求
Citadel内部签发证书主要有两种形式:
- 本身作为CA自己签发
- 作为RA代理CSR请求

服务列表中的istio-citadel是Istio的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。Citadel一直监听Kube-apiserver，以Secret的形式为每个服务都生成证书密钥，并在Pod创建时挂载到Pod上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向TLS认证、通道加密、访问授权等安全功能，这样用户就不用在代码里面维护证书密钥了。frontend服务对forecast服务的访问用到了HTTP方式，通过配置即可对服务增加认证功能，双方的Envoy会建立双向认证的TLS通道，从而在服务间启用双向认证的HTTPS。

1.1.3 Galley

Galley负责配置管理相关的工作。
Galley基本架构：

Admission Webhook提供配置校验
MCP Sink提供配置的摄取

1.1.4 Sidecar-lnjector

sidecar-injector是负责动态注入的组件，只要开启了自动注入，在Pod创建时就会自动调用sidecar-injector向Pod中注入Sidecar容器。在Kubernetes环境下，根据自动注入配置，Kube-apiserver在拦截到Pod创建的请求时，会调用自动注入服务sidecar-injector生成Sidecar容器的描述并将其插入原Pod的定义中。这样，在创建的Pod内除了包括业务容器，还包括Sidecar容器。这个注入过程对用户透明，用户使用原方式创建工作负载。

1.2 数据面

1.2.1 Envoy

istio的sidecar（istio-proxy）是开源项目envoy的扩展版，Envoy是用C＋＋开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，是istio架构中唯一的数据面组件，Envoy提供了动态服务发现、负载均衡、TLS，HTTP/2及gRPC代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能。在istio-proxy容器中除了有Envoy，还有一个pilot-agent的守护进程。

1.2.2 Pilot-Agent

Pilot-Agent基本架构：

渲染Envoy的启动模板，生成Bootstrap配置文件，最后启动Envoy进程
Envoy的守护功能
代理应用健康检查
NodeAgent SDS服务器，与Citadel协作
xDS代理
Local DNS服务

三、lstio无侵入的Sidecar基本原理

1.Sidecar基本介绍

将属于应用程序的功能拆分成单独的进程，这个进程可以被理解为Sidecar。在微服务体系内，将集成在应用内的微服务功能剥离到了sidecar内，sidecar提供了微服务发现、注册，服务调用，应用认证，限速等功能。

Sidecar自动注入，由Sidecar lnjector负责，支持按照Namespace以及按照应用注入
业务代码不感知Sidecar的存在
Sidecar负责拦截应用的流量，并且提供流量治理、安全、监控三大功能

sidecar容器内部运行着pilot-agent与envoy

Pilot-agent：基于kubernetes API资源对象为envoy初始化可用的bootstrap配置进行启动，在运行后管理envoy运行状态，如配置变更，出错重启等。
envoy：数据平面的执行层，由pilot-agent所启动的，从xDS API动态获取配置信息。Envoy并通过流量拦截机制处理入栈及出栈的流量。

2.Sidecar流量拦截

InitContainer或lstio-CNI设置iptables规则
流量拦截的流程

2.1 Sidecar流量拦截完整流程

sidecar通过注入到Pod中的init，执行在pod命名空间中设置iptable规则来完成流量捕获并管理。通过查看nsenter命令可以查看对应实现的内容。

iptables在NAT表中新建了4条链：ISTIO_INBOUND、ISTIO_IN_REDIRECT、ISTIO_OUTPUT、ISTIO_REDIRECT

[root@master01 ~]# nsenter -t `ps -ef|grep details|grep envoy|awk '{print $2}'` -n iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N ISTIO_INBOUND
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp -m tcp --dport 15008 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 22 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
# 到此入栈流量处理完成
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006# 这里开始执行出站流量
# 原地址为127.0.0.6/32 不做处理
-A ISTIO_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN
# 默认目标127.0.0.1/32--uid-owner 1337的由ISTIO_IN_REDIRECT处理
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
# 这些流量都不做处理。继续默认操作
-A ISTIO_OUTPUT -o lo -m owner ! --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
# 默认所有ISTIO_OUTPUT链的流量都由ISTIO_REDIRECT
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
# ISTIO_REDIRECT 的流量 默认有envoy进行处理转发到对应的应用
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001

流程说明：

当进入Pod的流量会被PREROUTING拦截处理。根据规则将数据包转发到ISOTIO_INBOUND。相关命令-A PREROUTING -p tcp -j ISTIO_INBOUND
ISTIO_INBOUND处理对应的规则，当遇到15008 22 15090 15021 15020不做处理，return给上一个链。
剩余流量从ISTIO_INBOUND转交给ISTIO_IN_REDIRECT。相关命令-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
ISTIO_IN_REDIRECT将流量交给15006端口应用处理。
Envoy根据数据包的目的地址查看Inbound方向的监听器配置，根据监听器及路由、Cluster、Endpoint等配置，决定是否将数据包转发到应用。
OUTPUT的流量由规则-A OUTPUT -p tcp -j ISTIO_OUTPUT由ISTIO_OUTPUT链处理。

3.Envoy基本介绍

envoy是作为微服务服务架构中以独立进程方式实现高级网络功能的，轻量级的7层服务代理程序，通常以sidecar的方式运行在应用程序的周边，也可以作为网络的边缘代理来运行
envoy的特性是进程外体系结构，L3/L4过滤器体系结构，HTTP L7过滤器体系结构，一流的HTTP/2支持，HTTP/3支持（目前为alpha），HTTP L7路由，gRPC支持，服务发现和动态配置，健康检查，高级负载平衡，前端/边缘代理支持，一流的可观察性

3.1 Envoy相关组件

Downstream：下游主机，指连接到Envoy的主机，这些主机用来发送请求并接受响应。
Upstream：上游主机，指接收来自Envoy连接和请求的主机，并返回响应。
Listener：服务或程序的监听器，Envoy暴露一个或多个监听器监听下游主机的请求，当监听到请求时，通过Filter Chain把对请求的处理全部抽象为Filter，例如ReadFilter、WriteFilter、HttpFilter等。
Cluster：服务提供集群，指Envoy连接的一组逻辑相同的上游主机。Envoy通过服务发现功能来发现集群内的成员，通过负载均衡功能将流量路由到集群的各个成员。
xDS：xDS中的x是一个代词，类似云计算里的XaaS可以指代IaaS、PaaS、SaaS等。DS为Discovery Service，即发现服务的意思。xDS包括CDS（cluster discovery service）、RDS（route discovery service）、EDS（endpoint discovery service）、ADS（aggregated discovery service），其中ADS称为聚合的发现服务，是对CDS、RDS、LDS、EDS服务的统一封装，解决CDS、RDS、LDS、EDS信息更新顺序依赖的问题，从而保证以一定的顺序同步各类配置信息。以上Endpoint、Cluster、Route的概念介绍如下：
- Endpoint：一个具体的“应用实例”，类似于Kubernetes中的一个Pod；
- Cluster：可以理解“应用集群”，对应提供相同服务的一个或多个Endpoint，类似Kubernetes中Service概念，即一个Service提供多个相同服务的Pod；
- Route：当我们做金丝雀发布部署时，同一个服务会有多个版本，这时需要Route规则规定请求如何路由到其中的某个版本上。xDS模块的功能是通过Envoy API V1（基于HTTP）或V2（基于gRPC），v3(当前支持的版本，支持start_tls,拒绝传入的tcp连接，4096位tls密钥，skyWalking和wasm等)实现一个服务端将配置信息暴露给上游主机，等待上游主机的拉取。

4.Envoy流量代理流程

LDS:istioctl pc listener{podname}
RDS:istioctl pc route{podname}
CDS:istioctl pc cluster{podname}
EDS:istioctl pc endpoint{podname}

xDS协议是"X Discovery Service"的简写，这里的"X"表示它不是指具体的某个协议，是一组基于不同数据源的服务发现协议的总称，包括CDS、LDS、EDS、RDS等。在Istio架构中，基于xDS协议提供了标准的控制面规范，并以此向数据面传递服务信息和治理规则。在Envoy中，xDS被称为数据平面API，并且担任控制平面Pilot和数据平面Envoy的通信协议。

CDS是Cluster Discovery Service的缩写，Envoy使用它在进行路由的时候发现上游Cluster。Envoy通常会优雅地添加、更新和删除Cluster。有了CDS协议，Envoy在初次启动的时候不一定要感知拓扑里所有的上游Cluster。在做路由HTTP请求的时候通过在HTTP请求头里添加Cluster信息实现请求转发。

EDS即Endpoint Discovery Service 的缩写。在Envoy术语中，Endpoint即Cluster的成员。Envoy通过EDS API可以更加智能地动态获取上游Endpoint。

LDS即Listener Discovery Service的缩写。基于此，Envoy可以在运行时发现所有的Listener，包括L3和L4 filter等所有的filter栈，并由此执行各种代理工作，如认证、TCP代理和HTTP代理等。添加LDS使得Envoy的任何配置都可以动态执行。

RDS即Router Discovery Service的缩写，用于Envoy在运行时为HTTP连接管理filter获取完整的路由配置，比如HTTP头部修改等。并且路由配置会被优雅地写入而无需影响已有的请求。当RDS和EDS、CDS共同使用时，可以帮助构建一个复杂的路由拓扑蓝绿发布等。

ADS、EDS、CDS等每个独立的服务都对应了不同的gRPC服务名称。对于需要控制不同类型资源抵达Envoy顺序的需求，可以使用聚合发现服务，即Aggregated xDS，它可以通过单一的gRPC服务流支持所有的资源类型，借助于有序的配置分发，从而解决资源更新顺序的问题。

5.Envoy流量匹配与转发

5.1 Envoy流量匹配与转发完整流程

概念：

LDS(Listener Discovery Service)：监听发现服务

RDS(Route Discovery Service)：路由发现服务

CDS(Cluster Discovery Service)：集群发现服务

EDS(Endpoint Discovery Service)：集群成员发现服务

流程：

1.Listener通过监听端口(10000)将请求根据Route提供的策略转发

2.Route可以配置路由规则，示例中转发到名字为「service_envoyproxy_io」的cluster

3.Cluster中可以配置行为相同的多个EndPoint，多个EndPoint可以配置负载均衡策略

4.EndPoint最终转发的节点地址

四、Istio服务网格基本功能实现原理

1.流量治理基本API

API	意义
ServiceEntry	定义Kubernetes集群外部服务，提供非K8s服务发现或者跨集群的服务发现
VirtualService	定义一些路由匹配、灰度、故障注入等功能
DestinationRule	提供目标服务的负载均衡策略以及连接管理，熔断等策略
Gateway	为服务网格边缘提供基本的流量转发策略

2.流量治理基本原理

2.1 Istio流量治理的基本流程

在控制面会经过如下流程：
（1）管理员通过命令行或者API创建流量规则；
（2）Pilot将流量规则转换为Envoy的标准格式；
（3）Pilot将规则下发给Envoy。

在数据面会经过如下流程：
（1）Envoy拦截Pod上本地容器的Inbound流量和Outbound流量；
（2）在流量经过Envoy时执行对应的流量规则，对流量进行治理。

3.服务发现

3.1 Istio服务发现的基本流程

服务发现与负载均衡，只是一个种策略实施的特例：

（1）提供服务的SvcB新增一个Pod（标号1）；

（2）在Pilot后台修改SvcB的集群配置（标号2）；

（3）Pilot将SvcB的最新信息同步给该配置的订阅方（标号3），即SvcB的调用方SvcA对应的Proxy；

（4）SvcA对应的Proxy增加到SvcB的链接（标号4），并实施负载均衡；

4.路由匹配

5.灰度发布

5.1 灰度发布的基本流程

按比例灰度发布

如上图所示，服务A调用服务B，服务B要发布一个灰度版本，需要5%的流量打到服务B的新版本，只需要：

（1）部署服务B的新版本；

（2）控制平面Pilot上进行策略配置，策略同步到Envoy；

（3）数据平面Envoy接收到策略配置，实时分流策略；

按流程灰度发布

如上图所示，服务B要发布一个灰度版本，需要把iPhone的流量打到B的新版本，操作流程完全一样（部署服务，Pilot控制，Envoy实施），非常方便。

如果Envoy原来只支持按照流量比例分流，不支持基于应用层协议分流，此时只需要：

（1）升级Envoy的分流策略，以及策略控制端Pilot；

（2）调用方服务A不需要升级；

（3）服务方服务B也不需要升级；

6.服务网格监控-Observability

Istio以非侵入的方式提供了以下遥测类型:

Metrics
Distributed Traces
Access Logs

6.1 服务网格监控-Metrics

6.2 服务网格监控-Trace

应用必须要从接收的请求中采集以下信息，并且发送给下一跳，这一点也证明服务网格并非完全零侵入

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context

依赖Envoy Tracer支持多种Trace后端:Zipkin Lightstep Datadog Stackdriver Opencensus Skywalking

Trace包含一个或者多个Span，Span表示一个逻辑单元，拥有起止时间并且包
含Metadata，每个Span又包含:

Originating service cluster setvia --service-cluster
Start time and duration of the request
Originating host set via–service-node
Downstream cluster set via the x-envoy-downstream-service-clusterheader.
HTTP request URL， method， protocoland user-agent.
Additional custom tags set via custom_tags.
Upstream cluster name， observability name， and address.
HTTP response status code.
GRPC response status and message (if available).
An error tag when HTTP status is 5xx or GRPC status is not’OK’

6.3 服务网格监控-AccessLog

总结

本文主要介绍的内容有：Istio的基本概念、Istio整体架构及工作原理、lstio无侵入的Sidecar基本原理、Istio服务网格基本功能实现原理。Istio是一个服务治理平台，治理的是服务间的访问，只要有访问就可以治理，不在乎这个服务是不是所谓的微服务，也不要求跑在其上的代码是否是微服务化的。

Istio在服务网络中统一提供的关键功能如下：

流量控制：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。
可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。

除此之外，Istio针对可扩展性进行了设计，以满足不同的部署需要：

平台支持：Istio旨在在各种环境中运行，包括跨云，预置，Kubernetes，Mesos等。最初专注于Kubernetes，但很快将支持其他环境。
集成和定制：策略执行组件可以扩展和定制，以便与现有的ACL，日志，监控，配额，审核等解决方案集成。

这些功能极大地减少了应用程序代码，底层平台和策略之间的耦合，使微服务更容易实现。

参考链接

lstio官方网站:https://istio.iol
ASM应用服务网格官方首页:https://supporthuaweicloud.com/istiol

本文整理自华为云社区【内容共创】活动第14期。

查看活动详情：https://bbs.huaweicloud.com/blogs/336904

相关任务详情：任务22.华为云云原生钻石课程12：Istio控制面架构深度剖析

【云驻共创】华为云云原生之Istio控制面架构深度剖析相关推荐

【云驻共创】华为云云原生之Kubernetes网络架构原理深度剖析（上）
文章目录前言一.Kubernetes诞生背景 1.云原生的概念 2.云原生架构 3.Kubernetes(k8s) 二.Kubernetes基本网络模型剖析 1.概念厘清 1.1 二层桥接 VS ...
【云驻共创】云原生应用架构之企业核心业务未来架构演进路线及华为云方案
文章目录前言一.企业核心业务架构演进 1.企业核心业务应用架构和集成架构发展历程 1.1 企业核心业务应用架构发展历程 1.1.1 单体架构 1.1.1.1 特点 1.1.1.2 优点 1.1.1 ...
【云驻共创】华为云AI之用Python定制我的《本草纲目女孩》
文章目录前言一.华为云ModelArts-Notebook介绍 1.华为云ModelArts-Notebook 1.1 Jupyter Notebook是什么 1.2 JupyterLab是什么 ...
【云驻共创】华为云之锁与权限为您的数仓保驾护航
文章目录前言 1.锁的介绍 2.权限的介绍一.DWS锁机制介绍&排查处理方法 1.华为云数仓DWS的概念 2.事务隔离性问题分析 3.数据库并发场景 4.锁机制 4.1 MVCC介绍 4. ...
【华为云-云驻共创】Docker是什么？有哪些应用场景？
文章目录前言容器技术的起源什么是容器? 容器与虚拟机为什么需要容器? 容器的优势对于开发人员 - Build Once, Run Anywhere 对于运维人员 - Configure On ...
【云驻共创】华为云HCIA-IoT V2.5培训系列内容之物联网概览
文章目录前言一.物联网发展简史与概述 1.物联网的发展简史 1.1 物联网的起源 1.2 物联网的发展 1.3 物联网大事件 1.3.1 NB-IOT标准的引进 1.3.2 工信部宣布5G商用 1 ...
【云驻共创】华为云IoTDA服务下的设备管理流程实操
文章目录一.当今社会发展趋势 1.社会背景 2.什么是物联网(IoT) 3.什么是华为云(IoTDA) 二.为什么需要设备发放 1.传统模式-存在问题 2.设备发放模式-问题改进三.设备接入服务的 ...
【云驻共创】华为云AI之《情感专家》在线分析影评情感基调
文章目录前言一.Word Embedding 二.BERT原理 1.Pre-training预训练 2.Deep Bidirectional Transformers 3.BERT中的双向表示 4 ...
【云驻共创】华为云IoT数据分析流程实操
文章目录一.数据分析的发展 1.数据分析概念 1.1 数据分析的背景 1.2 数据分析的目的 1.3数据分析的定义 2.物联网数据分析概念 3.华为云IoT数据分析优势二.华为云IoT数据分析服务 ...

【云驻共创】华为云云原生之Istio控制面架构深度剖析