1.需求背景 在微服务架构中，通常一个系统会被拆分为多个微服务，面对这么多微服务客户端应该如何去调用呢？如果根据每个微服务的地址发起调用，存在如下问题： 1.客户端多次请求不同的微服务，会增加客户端代码和配置的复杂性，维护成本比价高 2.认证复杂，每个微服务可能存在不同的认证方式，客户端去调用，要去适配不同的认证 3.存在跨域的请求，调用链有一定的相对复杂性（防火墙/浏览器不友好的协议） 4.难以重构，随着项目的迭代，可能需要重新划分微服务为了解决上面的问题，微服务引入了API网关的概念，API网关为微服务架构的系统提供简单、有效且统一的API路由管理，作
大家好，我是飘渺。如果你的微服务需要向第三方开放接口，如何确保你提供的接口是安全的呢？1.什么是安全接口通常来说，要将暴露在外网的API接口视为安全接口，需要实现防篡改和防重放的功能。1.1什么是篡改问题？由于HTTP是一种无状态协议，服务端无法确定客户端发送的请求是否合法，也不了解请求中的参数是否正确。以一个充值接口为例：http://localhost/api/user/recharge?user_id=1001&amount=10如果非法用户通过抓包获取接口参数并修改user_id或amount的值，就能为任意账户添加余额。1.1.1如何解决篡改问题？虽然使用HTTPS协议能对传输的明文
在微服务架构或者分布式系统中，客户端如何捕捉服务端的异常？这里说的客户端指调用方、服务端指被调用方，它们通常运行在不同的进程之中，这些进程可能运行在同一台服务器，也可能运行在不同的服务器，甚至不同的数据机房；其使用的技术栈可能相同，也可能存在很大的差异。为什么在Java、C#等高级语言中，程序遇到无法处理的情况，或者不满足运行条件时，比如除数是0的情况，底层代码通常会通过抛出异常（Exception）的方式向上层传递问题，上层代码通过try-catch的方式捕捉异常并进行处理，不过这种方式一般只能在同一个进程中使用，如果跨进程就没办法直接使用了。有的同学可能会问：为什么要跨进程传递异常呢？大家
微服务中的灰度发布（又称为金丝雀发布）是一种持续部署策略，它允许在正式环境的小部分用户群体上先部署新版本的应用程序或服务，而不是一次性对所有用户同时发布全新的版本。这种方式有助于在生产环境中逐步验证新版本的稳定性和兼容性，同时最小化潜在风险，不影响大部分用户的正常使用。1.灰度发布关键步骤在SpringCloud微服务架构中，实现灰度发布通常涉及到以下几个方面：流量分割：根据一定的策略（如用户ID、请求头信息、IP地址等）将流入的请求分配给不同版本的服务实例。使用SpringCloudGateway、Zuul等API网关组件实现路由规则，将部分请求定向至新版本的服务节点。版本标识：新版本服务启
在微服务架构中，服务之间的通信是至关重要的。今天我们将学习如何使用SpringCloud中的Feign来简化服务之间的调用，并处理通信过程中的异常情况。核心知识介绍Feign简介： Feign是一种声明性的、模板化的HTTP客户端。它使得编写Web服务客户端变得更加简单。我们可以通过Feign定义接口，然后通过注解方式来实现服务之间的调用，使代码更加简洁。服务调用： 我们将学习如何在一个微服务中使用Feign来调用另一个微服务的API。通过定义Feign客户端接口，我们可以像调用本地方法一样调用远程服务的方法。异常处理： 在服务之间的通信中，异常是不可避免的。我们将学习如何处理Feign调用中
我已经阅读了很多关于如何正确设置微服务的文章，而且我一直对一些较新的概念很感兴趣，包括:HAL、ALPS和HAL浏览器。我曾经记录过利用SwaggerUI的事情，但是，我开始明白以URL为中心不是正确的方法，我应该围绕资源和链接组织文档，这正是新技术的目的。我在这些较新的概念方面存在很多知识空白，因此我想正确理解这些技术如何协同工作，以便在我了解每一项技术时能够将它们融入到这个难题中。我目前的理解是:HAL-是JSON之上的一种附加格式，可让您通过链接在API中导航。ALPS-这是一种在JSON之上的附加格式，可以让我提供基于英语的描述来帮助描述我的资源HAL浏览器-以资源和链接为中心
1、前言为什么说是伪微服务框架，常见微服务框架可能还包括服务容错、服务间的通信、服务追踪和监控、服务注册和发现等等，而我这里为了在使用中的更简单，将很多东西进行了简化或者省略了。年前到现在在开发一个新的小项目，刚好项目最初的很多功能是比较通用的，所以就想着将这些功能抽离出来，然后做成一个通用的基础服务，然后其他项目可以直接引用这个基础服务，这样就可以减少很多重复的工作了。我在做的过程中也是参考了公司原有的一个项目，目标是尽量的简单，但是项目搞着搞着就越来越大了，所以我也是在不断的进行简化和优化。当然我的思考和架构能力还存在很大的问题，另外还由于时间比较仓促，很多东西还没有经过我的深思熟虑，而且
1.什么是FeignFeign是一种声明式、模板化的HTTP客户端，可用于调用HTTPAPI实现微服务之间的远程服务调用。它的特点是使用少量的配置定义服务客户端接口，可以实现简单和可重用的RPC调用。先来看我们以前利用RestTemplate发起远程调用的代码：存在下面的问题：•代码可读性差，编程体验不统一•参数复杂URL难以维护2.Feign远程调用2.1.Feign替代RestTemplateFegin的使用步骤如下：2.1.1.引入依赖我们在order-service服务的pom文件中引入feign的依赖：org.springframework.cloudspring-cloud-sta
第一章：综述1.1业务发展离不开微服务治理的保驾护航随着微服务技术的发展，微服务(MicroServices)的概念早已深⼊⼈⼼，也越来越多的公司开始使⽤微服务架构来开发业务应⽤。微服务架构的最⼤好处是它可以提升开发效率和系统整体的稳定性：开发和部署相对简单横向扩展简单架构升级灵活更好的容错性但是微服务在实施过程中，也很容易遇到⼀些难点。如果微服务治理得不恰当，反⽽有可能适得其反，不仅不能享受到微服务架构带来的好处，反⽽会因为微服务带来的系统复杂性，造成开发、运维部署的复杂度增加，进⽽影响开发迭代的速度，甚⾄影响系统的整体稳定性。一个微服务成功落地的典型案例业务孵化期组件技术选型+组件落地业务
公司微服务细分太多，最近跟我提说需要将几个微服务合为单体，经过几天的查阅，决定用二次打包的方式进行合并，然后部署的时候在nginx改下合并的微服务转发路劲即可，不需要前端修改路劲了。方案采用二次打包的方式进行合并，利用maven-dependency-plugin解压插件先将各微服务的jar包解压再用maven-assembly-plugin进行合并打包为一个jar包。合并前问题处理1、由于包合并时，相同的类会进行覆盖，会导致找不到类等，所以存在相同包下的相同类名作用不一致的话，需要调整下各服务的包名、类2、类注册的bean的name相同时，会导致注册bean失败，所以需要调整各服务有相同be
