精华内容
下载资源
问答
  • 如何解决微服务之间循环调用
    2022-03-26 15:46:53

    1.首先确定是不是在同一注册中心。
    2.确实微服务名唯一,不然可能会调到其他微服务中,导致错误。
    3.引入二个包 RestTemplate 和 DiscoveryClient 。
    4.通过获取注册提供的ip和端口进行调用。
    5.示例
    get请求
    @GetMapping("/test1")
    public Map consul() {
    List list = discoveryClient.getInstances(微服务名);
    ServiceInstance serviceInstance = list.get(0);
    String host = serviceInstance.getHost(); 微服务地址
    int port = serviceInstance.getPort();端口
    //指定请求地址为提供者,这里相当于网址和端口动态获取,但是后缀还是约定好的
    Map map= restTemplate.getForObject(“http://” + host + “:” + port + “/api/test/test/3”, Map.class).getBody;
    return map;
    }
    post请求
    @PostMapping("/test1")
    public Map consul(@ResquestBody Test test) {
    List list = discoveryClient.getInstances(微服务名);
    ServiceInstance serviceInstance = list.get(0);
    String host = serviceInstance.getHost(); 微服务地址
    int port = serviceInstance.getPort();端口
    JSONOBJECT jsonObeject=new JSONOBJECT ();
    jsonObeject.put(“test”,test);
    //指定请求地址为提供者,这里相当于网址和端口动态获取,但是后缀还是约定好的
    Map map= restTemplate.postForObject(“http://” + host + “:” + port + “/api/test/test”, jsonObeject,Map.class).getBody;
    return map;
    }

    更多相关内容
  • 相信大家平时开发的时候没少碰见,在微服务架构中需要调用很多服务才能完成一项功能。这时候,如何互相调用就变成微服务架构中的一个关键问题。在这里我介绍三个常用的方法

     相信大家平时开发的时候没少碰见,在微服务架构中需要调用很多服务才能完成一项功能。这时候,如何互相调用就变成微服务架构中的一个关键问题。在这里我介绍三个常用的方法

    一、RestTemplate方式

    @Bean
        public RestTemplate getRestTemplate(){
            return new RestTemplate();
        }

    服务的消费者(order)调用服务的提供者(Goods)

    @Autowired
        private RestTemplate restTemplate;
    
        @GetMapping("/createOrder/{gid}/{number}")
        public Order order(@PathVariable("gid") Integer id,@PathVariable("number") Integer number){
            log.info("用户开始下单,调用商品系统,查询{}号商品信息",id);
            Goods goods = restTemplate.getForObject("http://localhost:9002/goods/getGoods/" + id, Goods.class);
            log.info("商品信息查询完毕:"+ JSON.toJSONString(goods));
    
            log.info("开始下单:");
            Order order = new Order();
            order.setUid(1);
            order.setUname("测试用户");
            order.setGid(goods.getId());
            order.setGname(goods.getGoodsName());
            order.setNumber(number);
    
            orderService.createOrder(order);
            log.info("下单成功");
            return order;
        }

    通过上面的方式我们解决了微服务之间的相互调用,但是存在硬编码的问题,如果服务提供者的地址发生变化,就需要手工修改代码;如果有多个服务提供者,无法实现服务的负载均衡;如果服务增多,人工调用会变得更加的复杂。

    这个时候就会需要服务治理,服务治理是微服务架构最核心的问题,用于实现各个微服务的自动化注册与发现。在这里选择Nacos。

    二、引入Nacos注册中心

    1.在服务的提供者与消费者的pom文件中引入依赖

    <!--nacos客户端-->
            <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
            </dependency>

    2.在application.yml中添加配置

    spring:
      cloud:
        nacos:
          discovery:
            server-addr: 192.168.206.151:8848

    3.在对应的微服务上添加

    @EnableDiscoveryClient

    4.代码

       @Autowired
        private RestTemplate restTemplate;
       @Autowired
        private DiscoveryClient discoveryClient;
    
        @GetMapping("/createOrder2/{gid}/{number}")
        public Order order2(@PathVariable("gid") Integer id,@PathVariable("number") Integer number){
            log.info("用户开始下单,调用商品系统,查询{}号商品信息",id);
            //从nacos中获取服务地址
            ServiceInstance service = discoveryClient.getInstances("goods-service").get(0);
            String url = service.getHost() + ":" + service.getPort();
            //通过restTemplate调用
            Goods goods = restTemplate.getForObject("http://"+url+"/goods/getGoods/" + id, Goods.class);
            log.info("商品信息查询完毕:"+ JSON.toJSONString(goods));
    
            log.info("开始下单:");
            Order order = new Order();
            order.setUid(1);
            order.setUname("测试用户");
            order.setGid(goods.getId());
            order.setGname(goods.getGoodsName());
            order.setNumber(number);
    
            orderService.createOrder(order);
            log.info("下单成功");
            return order;
        }

    注:DiscoveryClient是专门负责服务注册和发现的,我们可以通过它获取到注册到注册中心的所有服务

    三、Fegin实现服务调用

    Feign是Spring Cloud提供的一个声明式的伪Http客户端, 它使得调用远程服务就像调用本地服务一样简单, 只需要创建一个接口并添加一个注解即可。

    Nacos很好的兼容了Feign, Feign默认集成了 Ribbon, 所以在Nacos下使用Fegin默认就实现了负载均衡的效果。

    在服务消费者上进行以下操作:

    1.添加依赖

    <!--fegin组件-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-openfeign</artifactId>
    </dependency>

    2.在启动类上添加注解

    @EnableFeignClients

    3.新建client包,并创建接口(把服务提供者controller对应的方法名复制过来,注意路径要完整。

    @FeignClient("goods-service")
    public interface GoodsService {
    
        @RequestMapping("/goods/getGoods/{id}")
        public Goods goods(@PathVariable("id") Integer id);
    }

    4.代码

    @Autowired
        private GoodsService goodsService;
    
        @GetMapping("/createOrder3/{gid}/{number}")
        public Order order3(@PathVariable("gid") Integer id,@PathVariable("number") Integer number){
            log.info("用户开始下单,调用商品系统,查询{}号商品信息",id);
    
            //通过feign调用商品微服务
            Goods goods = goodsService.goods(id);
            log.info("商品信息查询完毕:"+ JSON.toJSONString(goods));
    
            log.info("开始下单:");
            Order order = new Order();
            order.setUid(1);
            order.setUname("测试用户");
            order.setGid(goods.getId());
            order.setGname(goods.getGoodsName());
            order.setNumber(number);
    
            orderService.createOrder(order);
            log.info("下单成功");
            return order;
        }

    好了,先介绍到这里,想要以上demo的可以加微信领取,另外还有一份《Java最新2022版面试题及解答-阿里内部资料(266页)》可以免费送给大家。

    展开全文
  • 服务之间如何互相调用就变成微服务架构中的一个关键问题。服务调用有两种方式,一种是RPC方式,另一种是事件驱动(Event-driven)方式,也就是发消息方式。消息方式是松耦合方式,比紧耦合的RPC方式要优越,但RPC...

    在微服务架构中,需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。服务调用有两种方式,一种是RPC方式,另一种是事件驱动(Event-driven)方式,也就是发消息方式。消息方式是松耦合方式,比紧耦合的RPC方式要优越,但RPC方式如果用在适合的场景也有它的一席之地.

    耦合的种类:
    我们总在谈耦合,那么耦合到底意味着什么呢?

    1. 时间耦合:客户端和服务端必须同时上线才能工作。发消息时,接受消息队列必须运行,但后台处理程序暂时不工作也不影响。
    2. 容量耦合:客户端和服务端的处理容量必须匹配。发消息时,如果后台处理能力不足也不要紧,消息队列会起到缓冲的作用。
    3. 接口耦合:RPC调用有函数标签,而消息队列只是一个消息。例如买了商品之后要调用发货服务,如果是发消息,那么就只需发送一个商品被买消息。
    4. 发送方式耦合:RPC是点对点方式,需要知道对方是谁,它的好处是能够传回返回值。消息既可以点对点,也可以用广播的方式,这样减少了耦合,但也使返回值比较困难。

    下面我们来逐一分析这些耦合的影响。 第一,时间耦合,对于多数应用来讲,你希望能马上得到回答,因此即使使用消息队列,后台也需要一直工作。第二,容量耦合,如果你对回复有时间要求,那么消息队列的缓冲功能作用不大,因为你希望及时响应。真正需要的是自动伸缩(Auto-scaling),它能自动调整服务端处理能力去匹配请求数量。第三和第四,接口耦合和发送方式耦合,这两个确实是RPC方式的软肋。

    事件驱动(Event-Driven)方式:

    Martin Fowler把事件驱动分成四种方式(What do you mean by “Event-Driven”),简化之后本质上只有两种方式。 一种就是我们熟悉的的事件通知(Event Notification),另一种是事件溯源(Event Sourcing)。事件通知就是微服务之间不直接调用,而是通过发消息来进行合作。事件溯源有点像记账,它把所有的事件都记录下来,作为永久存储层,再在它的基础之上构建应用程序。实际上从应用的角度来讲,它们并不应该分属一类,它们的用途完全不同。事件通知是微服务的调用(或集成)方式,应该和RPC分在一起。事件溯源是一种存储数据的方式,应该和数据库分在一起。

    事件通知(Event Notification)方式:

    让我们用具体的例子来看一下。在下面的例子中,有三个微服务,“Order Service”, “Customer Service” 和“Product Service”.

    file

    图片来源

    先说读数据,假设要创建一个“Order”,在这个过程中需要读取“Customer”的数据和“Product”数据。如果用事件通知的方式就只能在“Order Service”本地也创建只读“Customer”和“Product”表,并把数据用消息的方式同步过来。

    再说写数据,如果在创建一个“Order”时需要创建一个新的“Customer”或要修改“Customer”的信息,那么可以在界面上跳转到用户创建页面,然后在“Customer Service”创建用户之后再发”用户已创建“的消息,“Order Service”接到消息,更新本地“Customer”表。

    这并不是一个很好的使用事件驱动的例子,因为事件驱动的优点就是不同的程序之间可以独立运行,没有绑定关系。但现在“Order Service”需要等待“Customer Service”创建完了之后才能继续运行,来完成整个创建“Order”的工作。主要是因为“Order”和“Customer”本身从逻辑上来讲就是紧耦合关系,没有“Customer”你是不能创建“Order”的。

    在这种紧耦合的情况下,也可以使用RPC。你可以建立一个更高层级的管理程序来管理这些微服务之间的调用,这样“Order Service”就不必直接调用“Customer Service”了。当然它从本质上来讲并没有解除耦合,只是把耦合转移到了上一层,但至少现在“order Service”和“Customer Service”可以互不影响了。之所以不能根除这种紧耦合关系是因为它们在业务上是紧耦合的。

    再举一个购物的例子。用户选好商品之后进行“Checkout”,生成“Order”,然后需要“payment”,再从“Inventory”取货,最后由“Shipment”发货,它们每一个都是微服务。这个例子用RPC方式和事件通知方式都可以完成。当用RPC方式时,由“Order”服务调用其他几个服务来完成整个功能。用事件通知方式时,“Checkout”服务完成之后发送“Order Placed”消息,“Payment”服务收到消息,接收用户付款,发送“Payment received”消息。“Inventory”服务收到消息,从仓库里取货,并发送“Goods fetched”消息。“Shipment”服务得到消息,发送货物,并发送“Goods shipped”消息。

    file

    图片来源

    对这个例子来讲,使用事件驱动是一个不错的选择,因为每个服务发消息之后它不需要任何反馈,这个消息由下一个模块接收来完成下一步动作,时间上的要求也比上一个要宽松。用事件驱动的好处是降低了耦合度,坏处是你现在不能在程序里找到整个购物过程的步骤。如果一个业务逻辑有它自己相对固定的流程和步骤,那么使用RPC或业务流程管理(BPM)能够更方便地管理这些流程。在这种情况下选哪种方案呢?在我看来好处和坏处是大致相当的。从技术上来讲要选事件驱动,从业务上来讲要选RPC。不过现在越来越多的人采用事件通知作为微服务的集成方式,它似乎已经成了微服务之间的标椎调用方式。

    事件溯源(Event Sourcing):

    这是一种具有颠覆性质的的设计,它把系统中所有的数据都以事件(Event)的方式记录下来,它的持久存储叫Event Store, 一般是建立在数据库或消息队列(例如Kafka)基础之上,并提供了对事件进行操作的接口,例如事件的读写和查询。事件溯源是由领域驱动设计(Domain-Driven Design)提出来的。DDD中有一个很重要的概念,有界上下文(Bounded Context),可以用有界上下文来划分微服务,每个有界上下文都可以是一个微服务。 下面是有界上下文的示例。下图中有两个服务“Sales”和“Support”。有界上下文的一个关键是如何处理共享成员, 在图中是“Customer”和“Product”。在不同的有界上下文中,共享成员的含义、用法以及他们的对象属性都会有些不同,DDD建议这些共享成员在各自的有界上下文中都分别建自己的类(包括数据库表),而不是共享。可以通过数据同步的手段来保持数据的一致性。下面还会详细讲解。

    file


    图片来源

    事件溯源是微服务的一种存储方式,它是微服务的内部实现细节。因此你可以决定哪些微服务采用事件溯源方式,哪些不采用,而不必所有的服务都变成事件溯源的。 通常整个应用程序只有一个Event Store, 不同的微服务都通过向Event Store发送和接受消息而互相通信。Event Store内部可以分成不同的stream(相当于消息队列中的Topic), 供不同的微服务中的领域实体(Domain Entity)使用。

    事件溯源的一个短板是数据查询,它有两种方式来解决。第一种是直接对stream进行查询,这只适合stream比较小并且查询比较简单的情况。查询复杂的话,就要采用第二种方式,那就是建立一个只读数据库,把需要的数据放在库中进行查询。数据库中的数据通过监听Event Store中相关的事件来更新。

    数据库存储方式只能保存当前状态,而事件溯源则存储了所有的历史状态,因而能根据需要回放到历史上任何一点的状态,具有很大优势。但它也不是一点问题都没有。第一,它的程序比较复杂,因为事件是一等公民,你必须把业务逻辑按照事件的方式整理出来,然后用事件来驱动程序。第二,如果你要想修改事件或事件的格式就比较麻烦,因为旧的事件已经存储在Event Store里了(事件就像日志,是只读的),没有办法再改。

    由于事件溯源和事件通知表面上看起来很像,不少人都搞不清楚它们的区别。事件通知只是微服务的集成方式,程序内部是不使用事件溯源的,内部实现仍然是传统的数据库方式。只有当要与其他微服务集成时才会发消息。而在事件溯源中,事件是一等公民,可以不要数据库,全部数据都是按照事件的方式存储的。

    虽然事件溯源的践行者有不同的意见,但有不少人都认为事件溯源不是微服务的集成方式,而是微服务的一种内部实现方式。因此,在一个系统中,可以某些微服务用事件溯源,另外一些微服务用数据库。当你要集成这些微服务时,你可以用事件通知的方式。注意现在有两种不同的事件需要区分开,一种是微服务的内部事件,是颗粒度比较细的,这种事件只发送到这个微服务的stream中,只被事件溯源使用。另一种是其他微服务也关心的,是颗粒度比较粗的,这种事件会放到另外一个或几个stream中,被多个微服务使用,是用来做服务之间集成的。这样做的好处是限制了事件的作用范围,减少了不相关事件对程序的干扰。详见"Domain Events vs. Event Sourcing".

    事件溯源出现已经很长时间了,虽然热度一直在上升(尤其是这两年),但总的来说非常缓慢,谈论的人不少,但生产环境使用的不多。究其原因就是应为它对现在的体系结构颠覆太大,需要更改数据存储结构和程序的工作方式,还是有一定风险的。另外,微服务已经形成了一整套体系,从程序部署,服务发现与注册,到监控,服务韧性(Service Resilience),它们基本上都是针对RPC的,虽然也支持消息,但成熟度就差多了,因此有不少工作还是要自己来做。有意思的是Kafka一直在推动它作为事件驱动的工具,也取得了很大的成功。但它却没有得到事件溯源圈内的认可(详见这里)。
    多数事件溯源都使用一个叫evenstore的开源Event Store,或是基于某个数据库的Event Store,只有比较少的人用Kafka做Event Store。 但如果用Kafka实现事件通知就一点问题都没有。总的来说,对大多数公司来讲事件溯源是有一定挑战的,应用时需要找到合适的场景。如果你要尝试的话,可以先拿一个微服务试水。

    虽然现在事件驱动还有些生涩,但从长远来讲,还是很看好它的。像其他全新的技术一样,事件溯源需要大规模的适用场景来推动。例如容器技术就是因为微服务的流行和推动,才走向主流。事件溯源以前的适用场景只限于记账和源代码库,局限性较大。区块链可能会成为它的下一个机遇,因为它用的也是事件溯源技术。另外AI今后会渗入到具体程序中,使程序具有学习功能。而RPC模式注定没有自适应功能。事件驱动本身就具有对事件进行反应的能力,这是自我学习的基础。因此,这项技术长远来讲定会大放异彩,但短期内(3-5年)大概不会成为主流。

    RPC方式:

    RPC的方式就是远程函数调用,像RESTFul,gRPC, DUBBO 都是这种方式。它一般是同步的,可以马上得到结果。在实际中,大多数应用都要求立刻得到结果,这时同步方式更有优势,代码也更简单。

    服务网关(API Gateway):

    熟悉微服务的人可能都知道服务网关(API Gateway)。当UI需要调用很多微服务时,它需要了解每个服务的接口,这个工作量很大。于是就用服务网关创建了一个Facade,把几个微服务封装起来,这样UI就只调用服务网关就可以了,不需要去对付每一个微服务。下面是API Gateway示例图:

    file

    图片来源

    服务网关(API Gateway)不是为了解决微服务之间调用的紧耦合问题,它主要是为了简化客户端的工作。其实它还可以用来降低函数之间的耦合度。 有了API Gateway之后,一旦服务接口修改,你可能只需要修改API Gateway, 而不必修改每个调用这个函数的客户端,这样就减少了程序的耦合性。

    服务调用:

    可以借鉴API Gateway的思路来减少RPC调用的耦合度,例如把多个微服务组织起来形成一个完整功能的服务组合,并对外提供统一的服务接口。这种想法跟上面的API Gateway有些相似,都是把服务集中起来提供粗颗粒(Coarse Granular)服务,而不是细颗粒的服务(Fine Granular)。但这样建立的服务组合可能只适合一个程序使用,没有多少共享价值。因此如果有合适的场景就采用,否侧也不必强求。虽然我们不能降低RPC服务之间的耦合度,却可以减少这种紧耦合带来的影响。

    降低紧耦合的影响:

    什么是紧耦合的主要问题呢?就是客户端和服务端的升级不同步。服务端总是先升级,客户端可能有很多,如果要求它们同时升级是不现实的。它们有各自的部署时间表,一般都会选择在下一次部署时顺带升级。

    一般有两个办法可以解决这个问题:

    1. 同时支持多个版本:这个工作量比较大,因此大多数公司都不会采用这种方式。
    2. 服务端向后兼容:这是更通用的方式。例如你要加一个新功能或有些客户要求给原来的函数增加一个新的参数,但别的客户不需要这个参数。这时你只好新建一个函数,跟原来的功能差不多,只是多了一个参数。这样新旧客户的需求都能满足。它的好处是向后兼容(当然这取决于你使用的协议)。它的坏处是当以后新的客户来了,看到两个差不多的函数就糊涂了,不知道该用那个。而且时间越长越严重,你的服务端可能功能增加的不多,但相似的函数却越来越多,无法选择。

    它的解决办法就是使用一个支持向后兼容的RPC协议,现在最好的就是Protobuf+gRPC,尤其是在向后兼容上。它给每个服务定义了一个接口,这个接口是与编程语言无关的中性接口,然后你可以用工具生成各个语言的实现代码,供不同语言使用。函数定义的变量都有编号,变量可以是可选类型的,这样就比较好地解决了函数兼容的问题。就用上面的例子,当你要增加一个可选参数时,你就定义一个新的可选变量。由于它是可选的,原来的客户端不需要提供这个参数,因此不需要修改程序。而新的客户端可以提供这个参数。你只要在服务端能同时处理这两种情况就行了。这样服务端并没有增加新的函数,但用户的新需求满足了,而且还是向后兼容的。

    微服务的数量有没有上限?

    总的来说微服务的数量不要太多,不然会有比较重的运维负担。有一点需要明确的是微服务的流行不是因为技术上的创新,而是为了满足管理上的需要。单体程序大了之后,各个模块的部署时间要求不同,对服务器的优化要求也不同,而且团队人数众多,很难协调管理。把程序拆分成微服务之后,每个团队负责几个服务,就容易管理了,而且每个团队也可以按照自己的节奏进行创新,但它给运维带来了巨大的麻烦。所以在微服务刚出来时,我一直觉得它是一个退步,弊大于利。但由于管理上的问题没有其他解决方案,只有硬着头皮上了。值得庆幸的是微服务带来的麻烦都是可解的。直到后来,微服务建立了全套的自动化体系,从程序集成到部署,从全链路跟踪到日志,以及服务检测,服务发现和注册,这样才把微服务的工作量降了下来。虽然微服务在技术上一无是处,但它的流行还是大大推动了容器技术,服务网格(Service Mesh)和全链路跟踪等新技术的发展。不过它本身在技术上还是没有发现任何优势。。直到有一天,我意识到单体程序其实性能调试是很困难的(很难分离出瓶颈点),而微服务配置了全链路跟踪之后,能很快找到症结所在。看来微服务从技术来讲也不全是缺点,总算也有好的地方。但微服务的颗粒度不宜过细,否则工作量还是太大。

    一般规模的公司十几个或几十个微服务都是可以承受的,但如果有几百个甚至上千个,那么绝不是一般公司可以管理的。尽管现有的工具已经很齐全了,而且与微服务有关的整个流程也已经基本上全部自动化了,但它还是会增加很多工作。Martin Fowler几年以前建议先从单体程序开始(详见 MonolithFirst),然后再逐步把功能拆分出去,变成一个个的微服务。但是后来有人反对这个建议,他也有些松口了。如果单体程序不是太大,这是个好主意。可以用数据额库表的数量来衡量程序的大小,我见过大的单体程序有几百张表,这就太多了,很难管理。正常情况下,一个微服务可以有两、三张表到五、六张表,一般不超过十张表。但如果要减少微服务数量的话,可以把这个标准放宽到不要超过二十张表。用这个做为大致的指标来创建微程序,如果使用一段时间之后还是觉得太大了,那么再逐渐拆分。当然,按照这个标准建立的服务更像是服务组合,而不是单个的微服务。不过它会为你减少工作量。只要不影响业务部门的创新进度,这是一个不错的方案。

    到底应不应该选择微服务呢?如果单体程序已经没法管理了,那么你别无选择。如果没有管理上的问题,那么微服务带给你的只有问题和麻烦。其实,一般公司都没有太多选择,只能采用微服务,不过你可以选择建立比较少的微服务。如果还是没法决定,有一个折中的方案,“内部微服务设计”。

    内部微服务设计:

    这种设计表面上看起来是一个单体程序,它只有一个源代码存储仓库,一个数据库,一个部署,但在程序内部可以按照微服务的思想来进行设计。它可以分成多个模块,每个模块是一个微服务,可以由不同的团队管理。

    file

    图片来源

    用这张图做例子。这个图里的每个圆角方块大致是一个微服务,但我们可以把它作为一个单体程序来设计,内部有五个微服务。每个模块都有自己的数据库表,它们都在一个数据库中,但模块之间不能跨数据库访问(不要建立模块之间数据库表的外键)。“User”(在Conference Management模块中)是一个共享的类,但在不同的模块中的名字不同,含义和用法也不同,成员也不一样(例如,在“Customer Service”里叫“Customer”)。DDD(Domain-Driven Design)建议不要共享这个类,而是在每一个有界上下文(模块)中都建一个新类,并拥有新的名字。虽然它们的数据库中的数据应该大致相同,但DDD建议每一个有界上下文中都建一个新表,它们之间再进行数据同步。

    这个所谓的“内部微服务设计”其实就是DDD,但当时还没有微服务,因此外表看起来是单体程序,但内部已经是微服务的设计了。它的书在2003就出版了,当时就很有名。但它更偏重于业务逻辑的设计,践行起来也比较困难,因此大家谈论得很多,真正用的较少。直到十年之后,微服务出来之后,人们发现它其实内部就是微服务,而且微服务的设计需要用它的思想来指导,于是就又重新焕发了青春,而且这次更猛,已经到了每个谈论微服务的人都不得不谈论DDD的地步。不过一本软件书籍,在十年之后还能指导新技术的设计,非常令人钦佩。

    这样设计的好处是它是一个单体程序,省去了多个微服务带来的部署、运维的麻烦。但它内部是按微服务设计的,如果以后要拆分成微服务会比较容易。至于什么时候拆分不是一个技术问题。如果负责这个单体程序的各个团队之间不能在部署时间表,服务器优化等方面达成一致,那么就需要拆分了。当然你也要应对随之而来的各种运维麻烦。内部微服务设计是一个折中的方案,如果你想试水微服务,但又不愿意冒太大风险时,这是一个不错的选择。

    结论:

    微服务之间的调用有两种方式,RPC和事件驱动。事件驱动是更好的方式,因为它是松耦合的。但如果业务逻辑是紧耦合的,RPC方式也是可行的(它的好处是代码更简单),而且你还可以通过选取合适的协议(Protobuf+gRPC)来降低这种紧耦合带来的危害。由于事件溯源和事件通知的相似性,很多人把两者弄混了,但它们实际上是完全不同的东西。微服务的数量不宜太多,可以先创建比较大的微服务(更像是服务组合)。如果你还是不能确定是否采用微服务架构,可以先从“内部微服务设计”开始,再逐渐拆分。

    展开全文
  • 循环调用问题

    2022-01-10 10:03:47
    此时不能有 //@Autowired // private UserService userService; 这两句话,否则会造成循环注入

    此时不能有

      //@Autowired

     // private UserService userService;

    这两句话,否则会造成循环注入

    展开全文
  • 微服务服务之间远程调用的几种方式(RestTemplate、Eureka、Nacos、feign)
  • 在一体化系统中,各个微服务也是不可能独立存在的,那么微服务之间涉及到的数据依赖问题,应该怎么处理呢?我们从场景入手来分析考虑此类问题。 一、场景 在一个供应链系统中,存在商品、销售订单、采购三个微服务,...
  • 之前我们介绍了通过服务网关来调用注册中心的微服务,但是各微服务之间怎样优雅简洁的相互调用呢?下面我们又引入一个新的组件:Feignhttps://github.com/OpenFeign/feign Feign是什么? (使用上注解是@Feign) ...
  • 微服务模块循环依赖
  • springframework.beans.factory.... nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name '...,我单独抽出Feign模块以做微服务之间调用...
  • 如题,现在工作中遇到这个问题,商品服务中有订单表,冗余了客户id;...也就是商品服务引用了客户服务,客户服务引用了商品服务,导致启动的时候报循环依赖的错误,这种有什么解决方法吗?尝试Pom文件排除,也没有用
  • 解决java.util.LinkedHashMap cannot be cast to xxx 实体类的问题 问题描述 1.最近在做分布式项目,需要用到其他子模块接口方法返回数据,遍历时候发生报错,如下图所示: 二。解决方法 1.解决思路:从list中取...
  • 为了方便取到或更新数据,服务之间可以随意的调用,以”微服务“为设计目标的系统会逐渐演变成一个分布式大单体,下图展示了三个服务之间的循环依赖关系: 另外循环依赖很可能导致一些循环调用或并发问题,...
  • 简单来说,就是如果订单服务对库存服务发起10次请求,那就先让你请求第1台机器、然后是第2台机器、第3台机器、第4台机器、第5台机器,接着再来—个循环,第1台机器、第2台机器。。。 以此类推 。 另外,Ribbon是...
  • 上篇文章 Spring Cloud中如何保证各个微服务之间调用的安全性 我们介绍了各个微服务之间调用认证的方式以及原理今天我们继续接着上篇文章来聊一聊如何能够在调用方实现token的自动设置以及刷新我们的认证token是...
  • 将一个单体项目拆分成微服务项目, 如何实现? 拆分原则: (1)微服务需要根据模块拆分, 做到单一职责, 不重复开发相同业务。 (2)微服务需要暴露业务接口, 供其他服务使用。 (3)不同微服务都应该有自己的...
  • 简介 ...微服务解决的到底是什么呢? 绝大多数人忘记了微服务的本质是用来解决什么问题的。 互联网应用在To C端有6秒之说,即一个小程序/APP应用打开和加载过程>6秒,肯定新用户就不会再去用了,4
  • 当项目越来越大,难免会遇到两个包相互调用的问题,先不提通过重构文件目录组织结构来避免这种情况,如果项目架构上大方向没有问题,尤其是项目排期紧张时,这时候我们就可以采用一种优雅的方式来绕过循环调用 ...
  • 【技术实现步骤摘要】本专利技术涉及计算机领域,具体涉及一种微服务中API调用统计和监控的方法。技术介绍现有的框架分布式SOA对性能要求很高,监控部分要求记录数据业务量,每天记录高达上亿次调用记录,传统的集中...
  • Springboot微服务调用超时处理

    千次阅读 2022-01-09 00:59:54
    在开发过程中,应用程序通常会和其他的应用进行交互,应用系统之间的交互往往离不开网络通信。然而,网络环境是不稳定的,网络超时是我们需要考虑的问题。交互模式同步同步调用同步调用接口返回两种状态...
  • 微服务并行调用多个外部接口

    千次阅读 2019-10-17 10:55:37
    线程池: 如何解决线程池中的线程被堵住的问题? 如果线程池被堵住, 将没有可用线程来执行新提交任务, 新提交任务将被存到任务队列等待执行。 例如, 在一个线程中并发请求多个其他外部接口, 一个折中的方案 既...
  • 通过上面的案例,我们已经可以会使用seata进行全局的分布式事物的使用了,在多微服务相互调用的环境中使用微服务. 然后咱们来看一下 首先我们看到对于seata来说,他有自己的数据库 seata,然后有branch_table表,有...
  • 》深入地阐述了微服务能够带来的利益,但是作为一项新兴的技术,总难免会遇到这样或那样的难题,今天就来一起看看微服务的难点之一:服务调用解决方案。微服务有很多难点,比如分布式系统:本文作者与红帽的顶级...
  • 数组 (在请求传递过程中,对请求做修改) - StripPrefix=1 #在请求转发之前去掉 gateway的一层路径 nacos: discovery: server-addr: localhost:8848 #将gateway 注册到nacos 5、运行微服务与nacos、即可实现调用 ...
  • 调用微服务server A,调用微服务server B 。 ①server A中定义两个服务接口。 ②server B中写一个接口C,接口上使用@FeignClient(value=server A)注解,接口内部通过url绑定server A的两个接口。 ③...
  • 微服务之间调用有两种方法: 1.负载均衡LoadBalancer整合RestTemplate 微服务的提供者配置文件的端口设置为port: ${port:9001}server: port: ${port:9001} 2.⼀种是和Feign相结合,Feign已经默认集成...
  • 循环体内的IO、远程调用,改为循环外去重后批量执行,避免重复发起调用 2. 数据库慢查询,优化SQL、索引 3. 基础的、频繁查询的方法,可以把执行结果放到缓存 4. 串行的远程调用可以改为并行。(慎用,请求高峰期会...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 20,334
精华内容 8,133
热门标签
关键字:

如何解决微服务之间循环调用