微服务中如何使用RestTemplate优雅调用API（拦截器、异常处理、消息转换）
在微服务中，rest服务互相调用是很普遍的，我们该如何优雅地调用，其实在Spring框架使用RestTemplate类可以优雅地进行rest服务互相调用，它简化了与http服务的通信方式，统一了RESTful的标准，封装了http链接，操作使用简便，还可以自定义RestTemplate所需的模式
〖Docker指南⑨〗本地一键部署微服务项目到阿里云服务器
想必大家都经历过手动上传文件到服务器上，然后手动解压等等一系列累人又无脑的操作，所以本次将在IDEA上整合docker，实现一键部署微服务项目，让你远离烦恼。 如果大家看了我前面的〖Docker指南〗系列，服务器里一定安装了docker，并且对docker的相关知识以及操作都了如指掌了。 那么接下来，所需要的就是一个微服务项目，小伙伴们可以自己搭建，也可以用我的，我已经把这个微服务demo上传到 Gitee【https://gitee.com/issavior/ossa】，大家可以自取。
白话微服务架构中的服务发现
如果你想跟朋友失去联系的最简单方法就是在不通知他们的情况下更改您的电话号码。同样适用于微服务架构系统中的服务。两个服务可能会愉快地相互通信，直到其中一个服务移动到另一个IP地址，而不通知对方，导致服务不可用。
SpringCloud微服务实战——搭建企业级开发框架（二十一）：基于RBAC模型的系统权限设计
RBAC（基于角色的权限控制）模型的核心是在用户和权限之间引入了角色的概念。取消了用户和权限的直接关联，改为通过用户关联角色、角色关联权限的方法来间接地赋予用户权限，从而达到用户和权限解耦的目的，RBAC介绍原文链接。 RABC的好处
SpringCloud微服务实战——搭建企业级开发框架（十七）：Sentinel+Nacos配置持久化
Sentinel Dashboard中添加的规则是存储在内存中的，我们的微服务或者Sentinel一重启规则就丢失了，现在我们将Sentinel规则持久化配置到Nacos中，在Nacos中添加规则，然后同步到Sentinel Dashboard服务中。Sentinel 支持以下几种规则：流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则 和 热点参数规则。具体可查看官网 Sentinel 规则
SpringCloud微服务实战——搭建企业级开发框架（十六）：集成Sentinel高可用流量管理框架【自定义返回消息】
Sentinel限流之后，默认的响应消息为Blocked by Sentinel (flow limiting)，对于系统整体功能提示来说并不统一，参考我们前面设置的统一响应及异常处理方式，返回相同的格式的消息。 1、在自定义Sentinel返回消息之前，需要调整一下代码结构，因为这里要用到统一返回异常的格式，考虑到后期可能的使用问题，
SpringCloud微服务实战——搭建企业级开发框架（十五）：集成Sentinel高可用流量管理框架【熔断降级】
Sentinel除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。由于调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断。
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微服务实战——搭建企业级开发框架（四）：集成SpringCloud+SpringBoot
1、在GitEgg工程的根目录，最上级父pom.xml文件中引入需要依赖的库及Maven插件，设置编码方式： 2、修改gitegg-service的pom.xml文件，引入需要的库： 3、在gitegg-service-system工程下新建GitEggSystemApplication主启动类：
一命通关——Docker与微服务（上）
docker从根本上解决换主机重新配置环境问题，因为docker把原始的配置环境也复制一份过来。此时的docker像一个容器装载着源代码+配置+环境+版本+各种第三方组件并将这些打包成一个镜像iso文件，让镜像文件在docker引擎上运行。更专业的来讲，docker给出了一个标准化的解决方案——系统平滑移植，容器虚拟化技术。
解决微服务架构下流量有损问题的实践和探索
绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。
浅析微服务全链路灰度解决方案
微服务全链路灰度解决方案，帮助应用发布版本过程中更精细化，提高了发布过程中的稳定性。服务转移⾄请求链路上进行流量控制，有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发，进⼀步促进业务的快速发展。
解决微服务架构下流量有损问题的实践和探索
绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。
如何基于盘古框架开发Dubbo微服务应用
本文介绍如何基于盘古开发框架开发一个微服务应用。文中所述仅为搭建一 个微服务应用的基本框架（服务注册&服务发现），如要增加配置中心、网关代理、数据持久化、缓存等能力请参考使用指南的相关章节。
CentOS 7.x安装微服务网关Apache APISIX
APISIX是基于云原生的微服务API网关，它是所有业务流量的入口，可以处理传统的南北向流量(server-client)，也可以处理服务间的东西向流量(server-server)，也可以当做 k8s ingress controller 来使用。
快速搭建微服务项目——SpringBoot+SpringCloud(使用maven方式搭建)
今天来教大家如何快速搭建一个微服务项目，其实很简单，首先使用编辑器新建一个maven项目，然后在pom.xml中添加相关的依赖包就好。
在微服务架构中管理技术债务
在 QCon Plus，Glenn Engstrand 谈到了一种促进技术债务管理的方法。 大多数参与软件开发的人员在试图让产品经理或项目经理同意他们花时间修复项目技术债务时都会遇到困难。 Engstrand 在 Optum Digital（前身为 Rally Health）采用的方法能够以一种系统性和非对抗的方式管理这些具有不同优先级的问题。
Google Kubernetes引擎上使用Istio简化微服务 — 第 III 部分（译）
Google Kubernetes引擎上使用Istio简化微服务 — 第 III 部分（译）
Devops 开发运维高级篇之Jenkins+Docker+SpringCloud微服务持续集成——部署方案优化
之前我们做的方案部署都是只能选择一个微服务部署并只有一台生产服务器，每个微服务只有一个实例，容错率低 如何去解决？
微服务架构：稳定性设计
通过依赖的管理，我们能够知道，当前系统调用了哪些服务，被哪些服务调用。接下来，我们便可以根据当前系统所依赖的服务，以及系统的流程，判断依赖的服务是否影响应用的流程，以此来决定当前应用依赖的优先级。
从零搭建微服务SpringCloud（二）新建一个SpringCloud项目
上文简述了什么是分布式与微服务， 以及Spring Cloud其实是微服务系统架构的一站式解决方案，是各个微服务架构落地技术的集合体。那么本文将讲述新建一个SpringCloud第一步需要的一些pom依赖配置。
在微服务架构下基于 Prometheus 构建一体化监控平台的最佳实践
个人认为将来可观测性一定是标准化且由开源驱动的。现在整个软件架构体系变得越来越复杂，我们要监控的对象越来越多，场景也越来越广。封闭的单一厂商很难面面俱到的去实现全局可观测能力，需要社区生态共同参与，用开放、标准的方法来构建云原生可观测性。
如何设计一个复杂的业务系统？从对领域设计、云原生、微服务、中台的理解开始
软件架构设计本身就是一个复杂的事情，但其实业界已有一个共识，那就是“通过组件化完成关注点的分离从而降低局部复杂度”。其实现在我们用的无论是容器、中间件、消息、数据库等，在某种意义上都是组件化的产物。这样的好处是在不同的系统里可以复用。在云原生兴起的今天，以通用的、组件化的服务形式更容易为我们所用，所以说现在如果还不享用云原生技术红利，那你就会被时代抛弃。
再深一点：如何给女朋友解释什么是微服务？
大家好，我是小羽。最近有很多粉丝私信：羽哥，羽哥！是不是失踪啦？好几个月没更新了！过气博主表示，工作也比较忙，加之自己搬家（没有叫货拉拉，懂的都懂，手动狗头）的原因，更文就落下了。现在终于...
springcloud学习笔记：认识微服务，谈资，技术的迭代演变，支付模块为例 体验demo（2）
springcloud学习笔记：认识微服务，谈资，技术的迭代演变，支付模块为例 体验demo（2）
