SpringCloud微服务实战——搭建企业级开发框架（二）：环境准备【上】
这里简单说明一下在Windows系统下开发SpringCloud项目所需要的的基本环境，这里只说明开发过程中基础必须的软件，其他扩展功能(Docker，k8s，MinIO，XXL-JOB，EKL，Keepalived，Nginx，RabbitMQ，Kafka等)用到的软件会在具体使用时详细说明，本地开发的环境软件以Windows版本的安装配置为例，数据库等中间件以Linux(CentOS7)的安装配置为例，其他系统Mac/Linux可自行配置
SpringCloud微服务实战——搭建企业级开发框架（十九）：Gateway使用knife4j聚合微服务文档
本章介绍Spring Cloud Gateway网关如何集成knife4j,通过网关聚合所有的Swagger微服务文档 1、gitegg-gateway中引入knife4j依赖,如果没有后端代码编写的话,仅仅引入一个swagger的前端ui模块就可以了
SpringCloud微服务实战——搭建企业级开发框架（十六）：集成Sentinel高可用流量管理框架【自定义返回消息】
Sentinel限流之后，默认的响应消息为Blocked by Sentinel (flow limiting)，对于系统整体功能提示来说并不统一，参考我们前面设置的统一响应及异常处理方式，返回相同的格式的消息。 1、在自定义Sentinel返回消息之前，需要调整一下代码结构，因为这里要用到统一返回异常的格式，考虑到后期可能的使用问题，
SpringCloud微服务实战——搭建企业级开发框架（十五）：集成Sentinel高可用流量管理框架【熔断降级】
Sentinel除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。由于调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断。
SpringCloud微服务实战——搭建企业级开发框架（十四）：集成Sentinel高可用流量管理框架【限流】
Sentinel 是面向分布式服务架构的高可用流量防护组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。Sentinel 安装部署请参考：https://www.jianshu.com/p/9626b74aec1e Sentinel 具有以下特性: • 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
SpringCloud微服务实战——搭建企业级开发框架（十三）：OpenFeign+Ribbon实现高可用重试机制
Spring Cloud OpenFeign 默认是使用Ribbon实现负载均衡和重试机制的，虽然Feign有自己的重试机制，但该功能在Spring Cloud OpenFeign基本用不上，除非有特定的业务需求，则可以实现自己的Retryer，然后在全局注入或者针对特定的客户端使用特定的Retryer。 在SpringCloud体系项目中，引入的重试机制保证了高可用的同时，也会带来一些其它的问题，如幂等操作或一些没必要的重试，下面我们实际操作来测试Spring Cloud架构中的重试机制。
SpringCloud微服务实战——搭建企业级开发框架（十一）：集成OpenFeign用于微服务间调用
作为Spring Cloud的子项目之一，Spring Cloud OpenFeign以将OpenFeign集成到Spring Boot应用中的方式，为微服务架构下服务之间的调用提供了解决方案。首先，利用了OpenFeign的声明式方式定义Web服务客户端；其次还更进一步，通过集成Ribbon或Eureka实现负载均衡的HTTP客户端。
SpringCloud微服务实战——搭建企业级开发框架（九）：使用Nacos发现、配置和管理微服务
Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台，Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos部署请参考Nacos安装指南：https://www.jianshu.com/p/2e065c15d730
SpringCloud微服务实战——搭建企业级开发框架（八）：使用注解校验微服务消息参数
平时开发过程中，经常要用到参数校验，如果直接在代码逻辑里面写参数校验，代码有点冗余且用起来不是非常方便，显得代码逻辑复杂且重复代码太多，这里我们使用注解的方式进行参数校验,SpringBoot中常用的用于参数校验的注解如下：
SpringCloud微服务实战——搭建企业级开发框架（六）：使用knife4j集成Swagger2接口文档
knife4j是为集成Swagger生成api文档的增强解决方案，前后端Java代码以及前端Ui模块进行分离,在微服务架构下使用更加灵活， 提供专注于Swagger的增强解决方案,不同于只是改善增强前端Ui部分，我们这里使用knife4j作为文档管理工具来代替swagger-ui。
面试官：微服务下数据一致性的有几种实现方式，分别说一下
本人最近学习了一下微服务下数据一致性的特点，总结了下目前的保障微服务下数据一致性的几种实现方式如下，以备后查。此篇文章旨在给大家一个基于微服务的数据一致性实现的大概介绍，并未深入展开，具体的实现方式本人也在继续学习中，如有错误，欢迎大家拍砖。 传统应用的事务管理 本地事务 在介绍微服务下的数据一致性之前，先简单地介绍一下事务的背景。传统单机应用使用一个RDBMS作为数据源。应用开启事务，进行CRUD，提交或回滚事务，统统发生在本地事务中，由资源管理器（RM）直接提供事务支持。数据的一致性在一个本地事务中得到保证。
从一个微服务应用的成功落地，谈企业需要什么样的微服务治理
随着微服务技术的发展，微服务(MicroServices) 的概念早已深入人心，越来越多的公司开始使⽤微服务架构来开发业务应用。
浅析微服务全链路灰度解决方案
微服务全链路灰度解决方案，帮助应用发布版本过程中更精细化，提高了发布过程中的稳定性。服务转移⾄请求链路上进行流量控制，有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发，进⼀步促进业务的快速发展。
解决微服务架构下流量有损问题的实践和探索
绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。
阿里云微服务引擎 MSE 2022年4月份产品动态
阿里云微服务引擎 MSE 2022 年 4 月产品动态。劳动最快乐，5月优惠不停，MSE 注册配置中心专业版首购享9折优惠，MSE 云原生网关预付费全规格享7折优惠。
在微服务架构中管理技术债务
在 QCon Plus，Glenn Engstrand 谈到了一种促进技术债务管理的方法。 大多数参与软件开发的人员在试图让产品经理或项目经理同意他们花时间修复项目技术债务时都会遇到困难。 Engstrand 在 Optum Digital（前身为 Rally Health）采用的方法能够以一种系统性和非对抗的方式管理这些具有不同优先级的问题。
Devops 开发运维高级篇之Jenkins+Docker+SpringCloud微服务持续集成——部署方案优化
之前我们做的方案部署都是只能选择一个微服务部署并只有一台生产服务器，每个微服务只有一个实例，容错率低 如何去解决？
Devops 开发运维高级篇之微服务持续集成代码上传和代码检查
微服务持续集成(1)-项目代码上传到Gitlab 微服务持续集成(2)-从Gitlab拉取项目源码 微服务持续集成(3)-提交到SonarQube代码审查
漫画：什么是微服务？
缺点一：项目过于臃肿，当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。 缺点二：资源无法隔离，就像刚刚小灰的经历一样，整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。
redis在微服务领域的贡献
说到redis，可能大家的脑海中蹦出的关键词是：NoSQL、KV、高性能、缓存等。但今天的文章从另一个角度——微服务来展开。 这篇文章的起因也是源自一次面试经历，在面试一位来自陌陌的候选人（就是那个交友的陌陌）时，他提到一点让我觉得很有意思，他说redis在陌陌被使用的非常广泛，除了常规的缓存外，某些场景下也当NoSQL数据库来使用，还用redis作为微服务的注册中心，甚至连RPC的调用协议都用了redis协议。
微服务架构：稳定性设计
通过依赖的管理，我们能够知道，当前系统调用了哪些服务，被哪些服务调用。接下来，我们便可以根据当前系统所依赖的服务，以及系统的流程，判断依赖的服务是否影响应用的流程，以此来决定当前应用依赖的优先级。
[半翻] 设计面向DDD的微服务
在DDD中，应用层依赖于领域和基础设施层，而基础设施依赖于领域层，但是领域层不依赖于任何层。 只在领域层编写业务规则和通用的领域知识，而应用层负责针对软件的目标来组合、协调领域层的业务规则。 领域层的领域实体、值类型、聚合根反映了真实业务的核心，需要用一种通用的语言来定义，这样不管应用层多么复杂，核心领域层自岿然不动。 领域层不能直接依赖与基础设施层，现代ORM框架一般都提出仓储模型来帮助领域层和技术设施层解耦。
SA实战 ·《SpringCloud Alibaba实战》快速搭建三大微服务并完成交互开发与测试
SA实战 ·《SpringCloud Alibaba实战》快速搭建三大微服务并完成交互开发与测试
