微服务

接下来的一段时间，我们将要来学习微服务，本着重实战的原则，你不需要去深究一些相关的原理，只要能跟着教程一步一步做下来，就可以快速地掌握Java微服务开发技巧。 我们学习微服务的第一步，就是要知道怎么创建聚合工程，虽然说微服务和聚合工程没有直接和必然的联系，但是现在工作中只要用到微服务，就一定是聚合工程。既然绕不开，我们就从聚合工程开始吧。

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

近年来随着互联网的飞速发展，各行各业都在拥 互联网。互联网给人类生活带来了翻天覆地的变化，人们在享受互联网给生活带来便捷的同时，业务需求的发展也对互联网技术提出了更高的要求，传统的单体架构对越来越复杂的业务需求显得力不从 此外，随着大数据云计算和人工智能的飞速发展，软件的架构显得越来越重要。近几年来，“微服务”这名词在各大网站、论坛、演讲中出现的频率足以让人们感觉到它对软件架构带来的影响 。目前，各大公司都在纷纷采用微服务架构。

10.3k？这才是企业级的 Spring Cloud Alibaba 微服务开发平台，真心牛 x！ 下

您需要模块，而不是微服务

如何设计一个复杂的业务系统？从对领域设计、云原生、微服务、中台的理解开始

如何正确的设计微服务

不同的微服务一般会有不同的网络地址，但 web 端或 APP 端需要调用多个服务的接口才能完成一个业务需求。在这种客户端直接与各个服务通信的架构时，会有以下问题： • 客户端需要维护很多服务的请求地址； • 客户端会多次请求不同的微服务，增加了客户端的复杂性； • 存在跨域请求，处理相对复杂； • 认证复杂，每个服务都需要独立认证； • 随着项目的迭代，可能需要重新划分微服务（多个微服务合并成一个或将一个服务拆分成多个），在客户端直接与微服务通信时，重构将会难以实施；

SpringCloud微服务框架01-SpringCloud简介

随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢？

开发团队越来越多地选择微服务架构而不是单体结构，以提高应用程序的敏捷性、可扩展性和可维护性。随着决定切换到模块化软件架构——其中每个服务都是一个独立的单元，具有自己的逻辑和数据库，通过 API 与其他单元通信——需要新的测试策略和新的测试工具。

模式语言提供了讨论问题的交流术语，它明确了特定场景、特定问题的解决方案和延伸性思考。模式语言主要目的是帮助开发者解决在设计和编程中遇到的共同的问题，即清晰的问题陈述、体现问题的解决方案以及推动解决方案的力量（Force）的清晰表述。 微服务架构作为一个现在流行的服务架构，也有一套属于自己的模式。这篇文章是微服务架构相关模式语言的一个提纲。Chris Richardson 从不同的角度，对相关的模式进行了分类。可以点击链接查看每个模式的详细描述。下图通过虚线框细分了不同的微服务模式。

如何构建基于 DDD 领域驱动的微服务？

如何构建基于 DDD 领域驱动的微服务？

Yii2.0如何进行微服务开发？具体步骤是怎样的？底层原理是什么？

开发者对于生产问题故障的排查、定位，随着微服务的喷发，也不再像是以前那边依赖纯日志、gc日志进行问题排查与定位了，本节开始介绍一个生产环境使用的排错工具Arthas，帮助大家更高效、便捷地实现生产问题排错。

Soul 网关在启动时，会从从配置服务同步配置数据，并且支持推拉模式获取配置变更信息，并且更新本地缓存。而管理员在管理后台，变更用户、规则、插件、流量配置，通过推拉模式将变更信息同步给 Soul 网关，具体是 push 模式，还是 pull 模式取决于配置。关于配置同步模块，其实是一个简版的配置中心。

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

Soul 是基于 WebFlux 实现的响应式的 API 网关，具有异步、高性能、跨语言等特点。 Git地址：https://github.com/Dromara/soul 运行环境： • MySQL 5.* • JDK 1.8+ • MAVEN 3.2.* • Git 更多原理性知识可以参考官网API：https://dromara.org/zh-cn/docs/soul/induction.html

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

前面已经分析了Watcher机制中的第一部分，即在org.apache.zookeeper下的相关类，接着来分析org.apache.zookeeper.server下的WatchManager类。

前面分析了FileSnap，接着继续分析FileTxnSnapLog源码，其封装了TxnLog和SnapShot，其在持久化过程中是一个帮助类。

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

在前面读者朋友们可以了解到ES承载着和MySQL一样的“存储-查询”功能，那么就类似的会有建表语句、表结构、表数据，有了这些才可以存储-查询数据。而这些对应的在ES中是：Mapping映射（表结构-建表语句）、索引库（表本身）、文档（表数据）。本节笔者将带领大家完整上述概念的创建、使用。

应用的硬件、软件架构在涉及到部署时，一般会根据实际请求量做一定的压力测试，以测试系统稳定性、健壮性，避免后续线上未知故障。假设在一个电商的秒杀场景下，订单中心本身能够承载的QPS预设是10W，因为活动的火爆导致流量瞬时达到100W，此时订单中心因无法承载其10倍的请求将会崩溃，那么对于整个分布式架构系统会产生什么问题呢？本节我们将借助于Sentinel的流量控制、隔离降级来解决上述分布式架构中常见的雪崩问题。

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

单机Redis可以解决应用缓存的问题，但是随着系统流量的增加，读操作开始指数级倍增时，及时单节点Redis基于内存的读写操作再快也会有性能瓶颈，此时我们可以借助主从架构（主负责写、从负责读）来优化上述场景，实现高并发读优化。

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

TCP/IP (Transmission Control Protocol/Internet Protocol，传输控制协议/互联网络协议）是Internet 的基本协议，简单地说，由底层的IP和TCP组成。TCP/IP的开发工作始于20世纪70年代，该协议是用于互联网的第一套协议。TCP/IP结合 DNS、路由协议等一系列相关协议，最终实现了网络之间任意两点间的数据通信问题。我们来看看在访问百度首页时，数据包是如何从计算机传送到百度的服务器上的。

从RabbitMQ 3.8版本开始，引入了新的仲裁队列，他具备与镜像队里类似的功能，但使用更加方便。

本节笔者介绍了SpringCloud诞生的由来，以及目前国内主要流行的SpringCloud Alibaba与SpringCloud的关系，同时针对SpringCloud自身的特点、版本号、依赖关系做了概要论述，这些都是为了接下来的实战打好基础。

基于常见组件的微服务场景实战，注册发现 下面开始微服务相关内容的讲解。在这一部分中，仍然从最基础的场景入手，然后再逐步展开说明，帮助大家快速掌握一些微服务组件的实现原理，最终理解微服务架构的本质。

DawnSql完美超越微服务