Spring Cloud Alibaba

这里记录下第一次和大佬级别的人物对话，事先准备了一堆问题，可临了又说不出个所以然，忐忑呀，不过挑了几个重点的问题，骆总给我的回复也是一针见血，指出了我现阶段存在的种种问题，道破了困扰许久的问题，我相信我目前遇到的，存在的问题也是大多数求职进阶路上的coder们正在面临的，或者已经经历过了的，轻喷。 从事IT行业，不管是主动还是被动，大家或多或少看到了他的发展，也预料过他的前景吧，尤疫情之后，蓬勃生机常在，就20日晚蚂蚁公司整栋的狂欢，作为拼命一线的码农来说，一夜之间的百万财富，我预想得到他们的欢呼是有多么的歇斯底里，歌声是有多么的嘹亮，这么看来从事这个行业真的是西天取经的路。 但是不少人会说我卖职业诱惑，我想卖职业诱惑的事交给培训机构就行了，我不卖诱惑，也不贩卖焦虑。 提起职业焦虑，35岁的梦，IT人的痛，从前段时间的996.ICU到如今的软件园跳楼事件，真的莫名觉得惋惜，5年的工作经验，忍忍总会过去的，翻越大山的人，最后被小石子绊倒了。但愿天堂没有加班！文末我会针对职业焦虑阐述下自己的一些看法。 下面是我这次对话的记录总结，提醒我自己，也鞭策我自己。 第一：如何学习？怎么学习？怎么快速突破自己？ 从事这个行业，我的工作年限不长，差半年到三年了，给我的第一感触就是需要花费大量的精力学习，不停的“缝缝补补”，不间断断的磕磕绊绊，但苦于市面上可获取知识的地方太多，渠道庞繁纷杂

作者 | 悟鹏 引子 性能测试在日常的开发工作中是常规需求，用来摸底服务的性能。 那么如何做性能测试？要么是通过编码的方式完成，写一堆脚本，用完即弃；要么是基于平台，在平台定义的流程中进行。对于后者，通常由于目标场景的复杂性，如部署特定的 workload、观测特定的性能项、网络访问问题等，往往导致性能测试平台要以高成本才能满足不断变化的开发场景的需求。 在云原生的背景下，是否可以更好解决这种问题？ 先看两个 yaml 文件： performance-test.yaml 描述了在 K8s 中的操作流程： 创建测试用的 Namespace 启动针对 Deployment 创建效率和创建成功率的监控 下述动作重复 N 次：① 使用 workload 模板创建 Deployment；② 等待 Deployment 变为 Ready 删除测试用的 Namespace basic-1-pod-deployment.yaml 描述使用的 workload 模板 performance-test.yaml ： apiVersion: aliyun.com/v1alpha1 kind: Beidou metadata: name: performance namespace: beidou spec: steps: - name: "Create Namespace If Not Exits"

“使用 ACK 容器服务可以帮助我们快速拉起测试环境，利用 PTS 即时高并发流量压测确认系统水位，结合 ARMS 监控，诊断压测过程中的性能瓶颈，最后通过 AHAS 对突发流量和意外场景进行实时限流降级，加上阿里云 团队保驾护航，保证了我们每一次大促活动的系统稳定性和可用性，同时利用 ACK 容器快速弹性扩缩容，节约服务器成本 50% 以上。” ——完美日记技术中台负责人 如果你对美妆产品略知一二，就一定听说过这个号称“国货之光”的品牌——完美日记。虽然完美日记主打的唇膏、唇釉、眼影等彩妆产品的市场竞争十分激烈，它却以惊人的增长速度杀出重围。2019 年仅用 8 个月时间，销量增长了近 50 倍，不但力压美康粉黛等国货同行而且全面赶超 YSL、SK-II 等国际大牌。 要知道，2016 年这个才刚刚诞生的品牌，2017 年才有了天猫旗舰店。而在 2018 年天猫 双11，第一次参与该活动的完美日记 ，仅用 90 分钟即突破 1 亿销售额；从 2019 年 1 月到 4 月，完美日记一直稳居天猫美妆销量第一；到了 2019 年 天猫618，完美日记第一小时就荣登天猫彩妆 Top1。截至 2020 年 4 月， 品牌 SKU 超过 700 个，全网用户粉丝数量超过 2500 万，月曝光量 10 亿 +。 对于一个爆款品牌，尤其是在消费品行业竞争如此激烈的情形下

作者 | 小马哥 **导读：**Dubbo 社区策划了【Dubbo 云原生之路】系列文章，和大家一起回顾 Apache Dubbo 产品和社区的发展，并展望未来发展。系列文章主要涵盖 Dubbo 技术解读、社区运营、应用案例解析三大部分。本文为系列第 3 篇。 前言 在 Java 微服务生态中， Spring Cloud 成为了开发人员的首选技术栈，然而随着实践的深入和运用规模的扩大，大家逐渐意识到 Spring Cloud 的局限性。 在服务治理方面，相较于 Dubbo 而言，Spring Cloud 并不成熟。遗憾的是，Dubbo 往往被部分开发者片面地视作服务治理的 RPC 框架，而非微服务基础设施。即使是那些有意将 Spring Cloud 迁移至 Dubbo 的小伙伴，当面对其中迁移和改造的成本时，难免望而却步。 庆幸的是，Dubbo 3.0 的到来将给这一局面带来重要变革，未来 Dubbo Spring Cloud 将无缝对接 Dubbo 3.0 ，作为 Spring Cloud Alibaba 的最核心组件，完全地拥抱 Spring Cloud 技术栈，不但无缝地整合 Spring Cloud 注册中心，包括 Nacos 、 Eureka 、 Zookeeper 以及 Consul ，而且完全地兼容 Spring Cloud Open Feign 以及

Dubbo 与开源中国共同策划 【Dubbo 云原生之路】 系列文章，和大家一起回顾 Apache Dubbo 产品和社区的发展，并展望未来发展。系列文章主要涵盖 Dubbo 技术解读、社区运营、应用案例解析三大部分。 本篇为系列第三篇。 系列文章： Dubbo 云原生之路 Dubbo 3.0 前瞻之：应用级服务发现 作者：小马哥（mercyblitz），Java 劝退师，《Spring Boot 编程思想》作者，Apache Dubbo PMC、Spring Cloud Alibaba 项目架构师。目前主要负责阿里集团中间件开源项目、微服务技术实施、架构衍进、基础设施构建等。 在 Java 微服务生态中， Spring Cloud 成为了开发人员的首选技术栈，然而随着实践的深入和运用规模的扩大，大家逐渐意识到 Spring Cloud 的局限性。 在服务治理方面，相较于 Dubbo 而言，Spring Cloud 并不成熟。遗憾的是，Dubbo 往往被部分开发者片面地视作服务治理的 RPC 框架，而非微服务基础设施。即使是那些有意将 Spring Cloud 迁移至 Dubbo 的小伙伴，当面对其中迁移和改造的成本时，难免望而却步。 庆幸的是，Dubbo3 的到来将给这一局面带来重要变革，未来 Dubbo Spring Cloud 将无缝对接 Dubbo3 ，作为 Spring

最近几年随着云计算和微服务不断的发展，各大云厂商也都看好了微服务解决方案这个市场，纷纷推出了自己针对微服务上云架构的解决方案，并且诞生了云原生，Cloud Native的概念。 云原生是一种专门针对云上应用而设计的方法，用于构建和部署应用，以充分发挥云计算的优势。 云原生应用的特点是可以实现快速和频繁的构建、发布、部署，可以方便的满足在扩展性，可用性，可移植性等方面的要求，并提供更好的经济性。 针对云原生，云厂商也纷纷提出了自己的解决方案，阿里巴巴开源的Nacos就是其中之一，Nacos同时集成到了Spring Cloud Alibaba中，作为一个整体的解决方案。 Nacos解决两个核心问题：动态配置管理，服务注册发现。 一、Nacos支持功能 Nacos支持以下的功能，包括服务发现，配置管理，元数据管理，地址服务器，支持云原生，支持Docker和K8s等。 服务发现 服务注册与发现 健康检查：支持服务端探测、客户端心跳 路由策略：支持权重、保护阈值、就近访问 配置管理 配置管理：支持发布、修改、查询、监听配置 灰度配置：支持灰度发布 元数据管理 对接第三方CMDB 地址服务器 支持Nacos寻址 云原生支持 对接Istio 对接ConfigMap 多客户端支持 支持多种客户端，包括Java客户端、Go客户端、Node.js客户端、C#客户端 支持Docker和K8s

package com.javaee.demo; import java.util.*; import java.io.*; public class FileDemo { public static void main(String[] args) { String path = "E:\\学习\\尚硅谷-全栈在线教育项目-谷粒学院【Vue.js+Spring Cloud Alibaba】\\课件\\谷粒学院笔记"; File file = new File(path); ForFile(file); } // 批量修改文件 public static void batchUpdate(String pathname) { File file = new File(pathname); String[] flist = file.list(); Arrays.asList(flist).stream().forEach(x -> { if (x.contains("ziw")) { String cc = x.replace("ziw", "zip"); File old = new File(pathname + File.separatorChar + x); File nfile = new File(pathname + File.separatorChar + cc);

作者 | 李志鹏 近几年，随着 Go 语言社区逐渐发展和壮大，越来越多的公司开始尝试采用 Go 搭建微服务体系，也涌现了一批 Go 的微服务框架，如 go-micro、go-kit、Dubbo-go 等，跟微服务治理相关的组件也逐渐开始在 Go 生态发力，如 Sentinel、Hystrix 等都推出了 Go 语言版本，而作为微服务框架的核心引擎--注册中心，也是必不可缺少的组件，市面已经有多款注册中心支持 Go 语言，应该如何选择呢？我们可以对目前主流的支持 Go 语言的注册中心做个对比。 图 1 根据上表的对比我们可以从以下几个维度得出结论： 生态 ：各注册中心对 Go 语言都有支持，但是 Nacos、 Consul、Etcd 社区活跃，zookeeper 和 Eureka 社区活跃度较低； 易用性 ：Nacos、Eureka、Consul 都有现成的管控平台，Etcd、zookeeper 本身作为 kv 存储，没有相应的管控平台，Nacos 支持中文界面，比较符合国人使用习惯； 场景支持 ：CP 模型主要针对强一致场景，如金融类，AP 模型适用于高可用场景，Nacos 可以同时满足两种场景，Eureka 主要满足高可用场景，Consul、Zookeepr、Etcd 主要满足强一致场景，此外 Nacos 支持从其它注册中心同步数据，方便用户注册中心迁移； 功能完整性

1. 前言 4月25号，Sentinel 1.6.0 正式发布，带来 Spring Cloud Gateway 支持、控制台登录功能、改进的热点限流和注解 fallback 等多项新特性，该出手时就出手，紧跟时代潮流，昨天刚发布，今天我就要给大家分享下如何使用！ 2. 介绍（本段来自Sentinel文档） Sentinel 1.6.0 引入了 Sentinel API Gateway Adapter Common 模块，此模块中包含网关限流的规则和自定义 API 的实体和管理逻辑： GatewayFlowRule：网关限流规则，针对 API Gateway 的场景定制的限流规则，可以针对不同 route 或自定义的 API 分组进行限流，支持针对请求中的参数、Header、来源 IP 等进行定制化的限流。 ApiDefinition：用户自定义的 API 定义分组，可以看做是一些 URL 匹配的组合。比如我们可以定义一个 API 叫 myapi，请求 path 模式为 /foo/ 和 /baz/ 的都归到 myapi 这个 API 分组下面。限流的时候可以针对这个自定义的 API 分组维度进行限流。 其中网关限流规则 GatewayFlowRule 的字段解释如下： • resource：资源名称，可以是网关中的 route 名称或者用户自定义的 API 分组名称。 •

项目地址 https://github.com/yinjihuan/kitty-cloud 前言 Kitty Cloud 开源后有以为朋友在 GitHub 上给我提了一个 issues，问为什么项目中要同时集成 Feign 和 Dubbo 两个框架来调用服务。今天就来聊一聊这个问题，然后讲下在 Kitty Cloud 中如何切换使用两种调用方式。 为什么要支持两种协议？ 关于支持两种协议，我这个是一个开源项目，主要还是为了让使用者有更多的选择。当然框架本身不是我开发的，我只是使用者而已。 一种协议更统一化，两种协议混着用也不是不可以，具体还是看实际需求。比如你们内部有个 ID 分发的服务，调用量很高，就是对性能有这极致的要求。那么这个场景你就可以用 Rpc 来代替 Http 了。其他的正常使用 Http 协议就行，特殊场景的就用 Rpc 协议，互补而已。 用 Http 最好的点在于简单，传输内容就是文本，调试什么的都很方便。比如我要单独测试某个服务的接口，直接 PostMan 上调用这个 Http 接口就可以了，或者用 Swagger。 如果是 Dubbo 的 Rpc, 我可能需要用 telnet 来调用。 还有就是网关层的转发，如果是 Http 协议，直接转发过去了。如果是 Rpc 协议，网关内部需要转特殊处理，当然目前也有支持 Rpc 的网关。如果我们是两种协议