微服务

[微服务架构 ]Saga 模式| 如何使用微服务实现业务事务 第一部分

Kubernetes 是一个开源的容器编排系统，最初由 Google 开发，后被 CNCF（Cloud Native Computing Foundation，云原生计算基金会）接手并继续推动发展。Kubernetes 的目标是提供一种可移植、可扩展和智能化的容器编排工具，可以自动化应用的部署、扩展和操作

（22）go-micro微服务kibana使用

（14）go-micro微服务服务层Handle开发

微服务创新时代，IPU打通未来数据中心之路

阿里云微服务引擎 MSE 面向业界主流开源微服务项目， 提供注册配置中心和分布式协调（原生支持 Nacos/ZooKeeper/Eureka ）、云原生网关（原生支持Higress/Nginx/Envoy，遵循Ingress标准）、微服务治理（原生支持 Spring Cloud/Dubbo/Sentinel，遵循 OpenSergo 服务治理规范）能力。

微服务实战05-服务链路追踪

微服务实战04-feign服务调用

EurekaServer ，它扮演的角色是注册中心，用于注册各种微服务，以便于其他微服务找到和访问。有了EurekaServer，还需要一些微服务，注册到EurekaServer上去。 这一节，我们来写一个注册微服务。为了简单起见，我们不用数据库，用java来模拟即可。

微服务实战01-maven聚合工程

聊聊 微服务 架构中的用户认证方案 上

东方证券：我们如何成功实施微服务

东方证券：我们如何成功实施微服务

如何正确的设计微服务

微服务中使用阿里开源的TTL，优雅的实现身份信息的线程间复用

3 个注解，优雅的实现微服务鉴权

好吧，标题似乎是一个大胆的陈述，所以让我们澄清一下我所说的微服务系统是什么意思。我不是指要在生产中使用的任何类型的框架，只是一个了解微服务架构的挑战以及它如何在幕后工作的项目。 我不打算将这个系列作为分步指南，因为到最后它可能至少有 100 篇文章。相反，我将尝试写关于设计选择、如何编写一些机制并突出一些有趣的问题（从全栈开发人员的角度来看）我在此过程中偶然发现。

因为微服务项目一般涉及的工程较多，所以在开发环境会把这些工程部署到虚拟机中，方便测试。 首先给出微服务开发虚拟机环境相关软件清单： Vagrant 2.2.10 VirtualBox 6.1.16 Windows PowerShell（windows 10 自带）

导言 今年似乎因为疫情影响，时间过得特别快，对于需要跳槽换工作的人来，更觉得有些突然，似乎金三银四和金九银四还没开始准备好，就匆匆过去。加上今年的大环境不佳，所以大部分的人在今年的招聘旺季都没有收获到好的结果。 今天分享的主题则是由 一位阿里P7的面试心得，通过32天的高效突击训练，成功拿下offer的学习方法。 篇章分为三大章节，可以根据自己所需来阅读内容和下载资料：

此章节将基于上一章节基础之上，引入Soul网关，至于Soul网关是干什么的，怎么做的，我们会在后续章节讲解，1-3章节侧重于搭建应用。 本章节的Soul网关接入，如果你1，2章节都是和我保持一致，那么只需要直接启动Soul网关即可，但是对应的provider，consumer应用是需要额外的代码接入的。 开发环境和第二章保持一致。

　　前面已经分析了Watcher机制中的大多数类，本篇对于ZKWatchManager的外部类Zookeeper进行分析。

前一篇已经分析了序列化，这篇接着分析Zookeeper的持久化过程源码，持久化对于数据的存储至关重要，下面进行详细分析。

随着应用数据的陡增，传统关系型数据库如MySQL/Oracle/RDS等，在处理海量数据的关系映射、数据查询场景还是有性能瓶颈。16年左右巅峰的Solr技术，随着近几年的技术发展也逐步被ES所替代。本节开始我们将花费5节的课程时间，带领读者朋友们认识ES、完成ES常见API的使用的代码演练。

作为分布式系统的接口测试工具，Jmeter在很多企业都有对应的使用场景，以满足开发者：接口性能测试，测试：接口瓶颈，实现系统上线前的稳定性保障。本节笔者将带领大家完成Jmeter工具的使用、介绍、说明。

在分布式架构系统中，服务不止一个，一个完整的业务链路肯定也不止调用一个服务，此时每个服务都有自己的数据库增删改查，而每一个写操作对应一个本地事务。如果想要确保全部的业务状态一致，也就意味着需要所有的本地事务状态一致，这在我们之前的学习中肯定是不具备的，如何做到跨服务、跨数据源的事务一致性将是本章节的重点学习内容。

在分布式架构系统中，服务不止一个，一个完整的业务链路肯定也不止调用一个服务，此时每个服务都有自己的数据库增删改查，而每一个写操作对应一个本地事务。如果想要确保全部的业务状态一致，也就意味着需要所有的本地事务状态一致，这在我们之前的学习中肯定是不具备的，如何做到跨服务、跨数据源的事务一致性将是本章节的重点学习内容。

消息中间件，作为分布式系统中必不可少的一部分，在前面我们学习过其基本的消息发送、消费（跳转链接），但是读者朋友们肯定也知道，真正的生产环境可不是简单的发送消息这么简单。如何避免消息丢失？如何满足特殊场景下的消息延迟消费？如何解决消费能力不足？如何搭建集群？等等 本节笔者将从消息的可靠性出发，解决消息不丢失的问题。同时借助TTL实现延迟消息，惰性队列解决消息堆积问题，最后完成集群搭建以实现生产环境真正的高可用。

Docker单机部署RabbitMQ

基于查询的数据解放涉及查询数据存储并将所选择的结果发布到相关的事件流中。一个使用合适的 API、SQL 或类 SQL 语言的客户端会被用于向数据存储请求特定的数据集。必须能够批量查询数据集以提供事件的历史记录，然后定期更新，以确保数据的更改被发布到输出事件流中。

前面处理了服务间数据依赖的场景。 除了这种频繁需要其他服务的数据的场景，其实还会碰到服务间依赖太杂乱的问题。 本篇讨论的就是如何缓解服务依赖复杂度的问题。 先把整个业务场景描述一下。

基于MSE实现微服务的全链路灰度-2