SpringCloud：Feign实现微服务之间相互请求
Feign是Netflix开发的声明式、模板化的HTTP客户端， Feign可以帮助我们更快捷、优雅地实现微服务之间的调用。 本文使用nacos、feign实现微服务之间访问。
认识微前端：一种用于前端 Web 开发的微服务
对于Web应用来说，前端越来越大，后端越来越不重要。现代 Web 应用程序 80%-90% 的代码为前端代码，后端代码非常少。可以想象，现在大多数新的web应用程序都面临着类似的情况。
Go+gRPC-Gateway(V2) 微服务实战，小程序登录鉴权服务(六)：客户端基础库 TS 实战
Go+gRPC-Gateway(V2) 微服务实战，小程序登录鉴权服务(六)：客户端基础库 TS 实战
前端云原生，以 Kubernetes 为基础设施的高可用 SSR(Vue.js) 渲染微服务初探（开源 Demo）
前端云原生，以 Kubernetes 为基础设施的高可用 SSR(Vue.js) 渲染微服务初探（开源 Demo）
NextArch 基金会旗下微服务标准化方案已开源：支持不同开发语言和技术框架
今年，腾讯、字节跳动、快手、BIGO、好未来、七牛云、中国移动、蓝色光标等多达 10 家企业和 go-zero/CloudWeGo/GoFrame/TARS 开源社区的技术专家，在 Linux 下一代架构基金会下成立了微服务技术组 SIG（Special Interest Group），共同探讨微服务治理标准化的解决方案，并向 NextArch 基金会提交了首个落地方案。
微服务中如何使用RestTemplate优雅调用API（拦截器、异常处理、消息转换）
在微服务中，rest服务互相调用是很普遍的，我们该如何优雅地调用，其实在Spring框架使用RestTemplate类可以优雅地进行rest服务互相调用，它简化了与http服务的通信方式，统一了RESTful的标准，封装了http链接，操作使用简便，还可以自定义RestTemplate所需的模式
SpringCloud微服务实战——搭建企业级开发框架（三十五）：SpringCloud + Docker + k8s实现微服务集群打包部署-集群环境部署【上】
一、集群环境规划配置 生产环境不要使用一主多从，要使用多主多从。这里使用三台主机进行测试一台Master（172.16.20.111），两台Node（172.16.20.112和172.16.20.113） 1、设置主机名 CentOS7安装完成之后，设置固定ip，三台主机做相同设置 vi /etc/sysconfig/network-scripts/ifcfg-ens33 #在最下面ONBOOT改为yes，新增固定地址IPADDR，172.16.20.111，172.16.20.112，172.16.20.113 ONBOOT=yes IPADDR=172.16.20.111
SpringCloud微服务实战——搭建企业级开发框架（三十二）：代码生成器使用配置说明
一、新建数据源配置 因考虑到多数据源问题，代码生成器作为一个通用的模块，后续可能会为其他工程生成代码，所以，这里不直接读取系统工程配置的数据源，而是让用户自己维护。
SpringCloud微服务实战——搭建企业级开发框架（二十六）：自定义扩展OAuth2实现短信验证码登录
我们系统集成了短信通知服务，这里我们进行OAuth2的扩展，使系统支持短信验证码登录。 1、在gitegg-oauth中新增SmsCaptchaTokenGranter 自定义短信验证码令牌授权处理类 2、自定义GitEggTokenGranter，支持多种token模式
SpringCloud微服务实战——搭建企业级开发框架（二）：环境准备【下】
这里简单说明一下在Windows系统下开发SpringCloud项目所需要的的基本环境，这里只说明开发过程中基础必须的软件，其他扩展功能(Docker，k8s，MinIO，XXL-JOB，EKL，Keepalived，Nginx，RabbitMQ，Kafka等)用到的软件会在具体使用时详细说明，本地开发的环境软件以Windows版本的安装配置为例，数据库等中间件以Linux(CentOS7)的安装配置为例，其他系统Mac/Linux可自行配置
SpringCloud微服务实战——搭建企业级开发框架（十六）：集成Sentinel高可用流量管理框架【自定义返回消息】
Sentinel限流之后，默认的响应消息为Blocked by Sentinel (flow limiting)，对于系统整体功能提示来说并不统一，参考我们前面设置的统一响应及异常处理方式，返回相同的格式的消息。 1、在自定义Sentinel返回消息之前，需要调整一下代码结构，因为这里要用到统一返回异常的格式，考虑到后期可能的使用问题，
SpringCloud微服务实战——搭建企业级开发框架（六）：使用knife4j集成Swagger2接口文档
knife4j是为集成Swagger生成api文档的增强解决方案，前后端Java代码以及前端Ui模块进行分离,在微服务架构下使用更加灵活， 提供专注于Swagger的增强解决方案,不同于只是改善增强前端Ui部分，我们这里使用knife4j作为文档管理工具来代替swagger-ui。
解决微服务架构下流量有损问题的实践和探索
绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。
SpringCloud 微服务实战笔记
这是很早以前在我的博客上写的关于 SpringCloud 的一些实战笔记，现在我把这些实战笔记集合起来贴到这里，可能会对一些刚刚接触 SpringCloud 微服务的小伙伴有帮助。
从一个微服务应用的成功落地，谈企业需要什么样的微服务治理
随着微服务技术的发展，微服务(MicroServices) 的概念早已深入人心，越来越多的公司开始使⽤微服务架构来开发业务应用。
解决微服务架构下流量有损问题的实践和探索
绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。
基于SpringCloudGateway实现微服务网关
后端写完所有的微服务之后，最终是要交给前端去调用。我们都知道每个微服务都有各自的端口号，如果前端直接通过IP加端口的方式去调用微服务会很麻烦。如果想对请求增加限制也会变得十分困难。这个时候微服务网关就出现了。
redis在微服务领域的贡献
说到redis，可能大家的脑海中蹦出的关键词是：NoSQL、KV、高性能、缓存等。但今天的文章从另一个角度——微服务来展开。 这篇文章的起因也是源自一次面试经历，在面试一位来自陌陌的候选人（就是那个交友的陌陌）时，他提到一点让我觉得很有意思，他说redis在陌陌被使用的非常广泛，除了常规的缓存外，某些场景下也当NoSQL数据库来使用，还用redis作为微服务的注册中心，甚至连RPC的调用协议都用了redis协议。
微服务架构：稳定性设计
通过依赖的管理，我们能够知道，当前系统调用了哪些服务，被哪些服务调用。接下来，我们便可以根据当前系统所依赖的服务，以及系统的流程，判断依赖的服务是否影响应用的流程，以此来决定当前应用依赖的优先级。
Dubbo-go-Mesh 开启新一代 Go 微服务形态
Proxyless Service Mesh 能力将跟随 Dubbo-go 下一版本发布，稳定的性能需要社区成员们共同的关注与建设。在此基础之上，我们还会进一步探索轻量级 sdk + sidecar的模型；探索基于第三方流量治理组件的金丝雀发布能力；探索基于 dubbo 服务框架的多语言 sevice mesh、与更丰富的 mesh 生态组件兼容。
从零搭建微服务SpringCloud（四）设计SpringCloud服务提供者
上文中讲到SpringCloud注册中心应该如何去创建以及配置。那么我们知道Eureka具体可以做什么之后，就可以开始设计微服务-服务提供者了。
