llg___的博客

XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。该阶段下，事务的协调者向事务参与者RM发起一个准备的请求，RM执行完SQL后不提交，返回给事务协调者一个就绪的状态。seata的XA模式做了一些调整和封装，并引入了TM，即事务管理器。对应的，RM在第二阶段则等待接收TC指令，准备提交或回滚事务。

这里用一个简单的SpringCloud项目来演示如何集成OpenTelemetry，项目中有三个服务，网关gateway、订单服务order、用户服务user，且order通过Feign远程调用user，最后数据导出到zipkin。（OpenTelemetry专注的是生成、收集、导出，存储和可视化的事儿交给其他工具，如ZipKin、Jager）

即OpenTelemetry 是一个可观测性框架，它不像Jaeger、Prometheus，而是专注于生成、收集 、导出Telemetry遥测数据（Metrics,Logs and traces）。存储和可视化数据的事儿则留给其他工具，比如Zipkin、Jageger、skywalking、Prometheus等…

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。官网。

此时就出现了悖论，网络故障期间，如果所有节点仍然对外提供服务，则可用性A成立，但数据不一致了，即C不成立。如果节点node03暂时不提供服务，此时返回的01和02节点返回的数据当然是一致的，即C成立，但可用性A不成立。在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，而这些分支事务之间互相无感知，要保证所有分支事务最终状态一致，这样的事务就是分布式事务。但微服务下，一个业务可能跨越多个微服务，而每个服务又会有自己的数据库，这个时候，仅靠数据库自身，已经不能保证业务上的ACID了。

Zipkin 是 Twitter 的一个开源项目，基于 Google Dapper 实现，致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。# 官方文档 https://zipkin.io/pages/quickstartController：收集器，处理从外部系统发送过来的跟踪信息，将这些跟踪信息处理成Zipkin需要的Span格式，以便后面的存储、分析、展示Storage：存储，处理收集器接收到的跟踪信息，默认存于内存，可改为MySQL、ES等。

通过分析这些数据，开发人员可以确定系统中哪些服务或系统调用是性能瓶颈，并确定它们对系统整体性能的影响。随着互联网业务快速扩展，软件架构也日益变得复杂，为了适应海量用户高并发请求，系统中越来越多的组件开始走向分布式化，如单体架构拆分为微服务、服务内缓存变为分布式缓存、服务组件通信变为分布式消息，这些组件共同构成了繁杂的分布式网络。Zipkin 是 Twitter 的一个开源项目，基于 Google Dapper 实现，致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。

服务A要等待服务D的结果，而服务D已经不能正常响应了，此时服务A内部阻塞，不会释放tomcat的连接（此时服务A依赖于服务B的业务还是不受影响）。比如到服务A–服务D的这个请求，访问了三次，两次失败，即66%异常，阈值如果设为50%，则此时发生熔断，后续再有这个请求过来直接拦截，快速失败，立刻释放资源，从而解决雪崩问题。即某个服务故障，最终导致了依赖它的某个服务也故障了。这只能缓解雪崩问题，而不能彻底根除，因为比如设置等待1s就释放1个连接，但一秒钟之内进来了2个请求，终有一天，服务A的资源也可能被耗尽。

默认情况下，Bucket聚合会统计Bucket内的文档数量，记为_count，并且按照_count降序排序。这里获取筛选信息的接口有传参，是因为，如果筛选项是对索引库全部数据进行聚合，就会出现这个场景;即，我已经搜了上海虹桥了，但底下的城市过滤项还有其他城市，因此要对聚合加过滤条件。统计所有数据中的酒店品牌有几种，此时可以根据酒店品牌的名称做聚合。看到这个格式，最先想到的数据格式应该是Map。

接下来添加品牌、城市、星级、价格的过滤功能。这里参与搜索的条件对应着不同的搜索类型，有全文检索，有精确查找，自然要用复合查询Boolean Search。从页面分析，我们需要实现搜索、分页、排序等功能。接下来实现根据这个坐标，将酒店结果按照到这个点的距离升序排序。接下来实现酒店搜索功能，完成关键字搜索和分页。重启服务，搜索和分页已实现。

如下图，和同步调用不一样的时，当用户支付完成，支付服务将信息传递给Broker以后，由Broker去通知后面的订单服务、发送短信服务等来干活儿，这几个服务什么时候干完活儿，支付服务已经不再关心了。当大量用户请求服务时，Broker就像一个拦在洪水前的大坝，保护着后面的服务不受影响，这些服务仍然按照它们的并发能力从Broker中拿消息并处理请求即可。最后，实际开发中，到底是同步调用还是异步调用，看具体需要什么，需要信息的时效性，则同步调用，需要的是高并发，则异步调用。此时，查看控制台，可以看到消息发送成功。

网关是什么？网关的搭建。路由断言。路由过滤器、全局过滤器、限流过滤器、过滤器的执行顺序以及跨域问题的处理服务就像一个景点，如果人人可以访问，不管是游客还是搞破坏的人都放进来，那一定出事。由此，景区增加了统一入口，设保安，给游客指路，并对每日访客流量进行控制。

Feign是什么?如何基于Feign实现远程调用？报错：xxxService required a bean of type 'com.feign.client.UserClient' that could not be found.自定义Feign有两种方式：远程调用所有服务都这样。如果是写服务名称，则是针对某个微服务的配置 loggerLevel : FULL # 日志级别。

Nacos安装、Nacos负载均衡策略、Nacos集群搭建服务消费者每30秒拉取一次新的信息，并存入列表缓存，但如果两次拉取的期间有服务实例挂了，则信息更新不及时。引入集群的概念，其实是做个划分：服务调用尽可能选择本地集群的服务，跨集群调用延迟较高本地集群不可访问时，再去访问其它集群。目前，naocs的地址写在application.yaml中，但根据上面的读取顺序，先读取的是nacos配置，所以得。有的配置，在很多环境中都要用到，如果每个里面都写一份，冗余不说，后期有变更时，也只能一个个去改，不方便。

我在浏览器中直接访问http://userservice/user/，访问失败，这是因为userservice既不是可用域名，也不是IP。上一篇中，远程调用时，url参数是写死在代码中的，而不同的测试、生产、开发环境IP不同，有集群时，端口也不能固定。接下来实现：在order服务中完成服务信息的拉取，然后通过负载均衡挑选一个user服务，实现远程调用。Ribbon的负载均衡策略是由IRule接口来定义的，它的每一个子接口就是一种策略。服务消费者：一次业务中，调用其它微服务的服务。（提供接口给其它微服务）

在需要远程调用其他服务的方法中，使用restTemplate对象，调用getForObject方法或者postForObjecct方法，传入调用的url，和需要的类型（就可以json反序列化出User.class类型的对象）到此，可以看到拆分完成，不同的模块干不同的职责，order模块查订单，user模块查用户。相比单体架构，分布式架构则是根据业务功能对系统进行拆分，每个业务模块做为独立项目开发，成为一个个服务。隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题（一个服务挂了，向依赖的服务全挂了）