微服务

微服务框架：如果不用 Spring Boot，还可以选择谁？

本人18年毕业于长沙某大专，实习期间进入一家和学校合作的互联网公司，一直在公司干着千篇一律的CRUD，生活看不到希望，感觉一直在这里CRUD没有希望，所以在春节回来后就离职了，一直在家中学习。和一些大佬在VX群里交流学习的过程中，无意中从一位腾讯云大佬手中拿到了这份由腾讯云大佬亲码的“Java微服务”学习笔记！

微服务架构 目前微服务是非常火的架构或者说概念，也是在构建大型互联网项目时采用的架构方式。随着业务需求的快速发展变化，需求不断增长，迫切需要一种更加快速高效的软件交付方式。而微服务可以弥补单体应用不足，是一种更加快速高效的软件架构风格。

相信大家在网上会看到很多帖子把分布式跟微服务放在一起讨论。确实，微服务就是一种分布式架构的设计方法。但是，在微服务概念还没有出现之前，分布式这个概念并不能引起人们的强烈关注，如果说自己擅长分布式架构设计，可能没有多少人理你，但如果说自己精于微服务架构设计，情况那就大不一样了。有关于微服务的优点，网上大把的文章已经说的很清楚了，我就不细说了，简单来说微服务能够创建一个“打不垮”的系统。以至于现在，微服务架构已经成为家公司技术 是否先进、是否具有规模发展的标杆配置。

为什么会有微服务？ 假如回到10年前，一天张三入职了电商企业—并夕夕商城。 公司初创，人比较少，公司网站的用户也很少，公司只有一个工程师 项目架构比较简单

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

了解一下数据库设计，可以帮助我们对于Soul框架有更好的认知

前面学习了Zookeeper相关细节，其中对于集群启动而言，很重要的一部分就是Leader选举，接着就开始深入学习Leader选举。

本篇博文详细分析了FastLeaderElection的算法，其是ZooKeeper的核心部分，结合前面的理论学习部分，可以比较轻松的理解其具体过程。

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

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

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

在上面两节，笔者带领大家完成主动集群搭建（解决单节点读压力过大问题），又完成哨兵集群的搭建（解决节点故障的自动恢复，从而提高系统整体稳定性）。但是上述不论那种架构模式，都没有解决当前系统的写压力过大问题。本节的分片集群将会有多个master节点，实现写压力的分摊，同时多个master节点互相通信，具备哨兵的功能，一旦节点故障，同样可以自动检测、投票、恢复。

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

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

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

分布式系统从诞生到现在已经有几十个年头了，其中伴随着一些很重要的基础理论，正是这些影响深远的基础理论，奠定了分布式系统的坚实基础，造就了分布式领域的一座座宏伟大厦。为了练就一身武功，让我们从这些经典的分布式理论开始学起吧。

仅仅懂了Socket编程还不够,因为我们不是简单地写一个发送字符串的Hello World程序，需要实现复杂的对象实例传输，因此，如何将一个对象实例编码成为高效的二进制数据报文传输到对端，并且正确地“还原”出来，就是一个专业的技术问题了。

在RabbitMQ的官方文档中，讲述了两种集群的配置方式： ● 普通模式：普通模式集群不进行数据同步，每个MQ都有自己的队列、数据信息（其它元数据信息如交换机等会同步）。例如我们有2个MQ：mq1，和mq2，如果你的消息在mq1，而你连接到了mq2，那么mq2会去mq1拉取消息，然后返回给你。如果mq1宕机，消息就会丢失。 ● 镜像模式：与普通模式不同，队列会在各个mq的镜像节点之间同步，因此你连接到任何一个镜像节点，均可获取到消息。而且如果一个节点宕机，并不会导致数据丢失。不过，这种方式增加了数据同步的带宽消耗。

对于http接口的调用，其历程经历过原始servlet，到后面的struts，SpringMVC，对于后端的参数封装也逐渐从单个属性演变成对象封装，那么什么是RESTful，工作中又如何使用呢？

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

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

通过从实体事件流中按顺序处理实体事件，可以将信息物化成一个有状态的表。每个实体事件都会被更新插入键/值表中，这样对于一个给定的键，表中表示的就是最新读到的事件。

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

上面讲解了数据一致性的解决方案，这一篇来讲讲服务之间的数据依赖问题，还是先来说说具体的业务场景。 业务场景：如何解决微服务之间的数据依赖问题 在某个供应链系统中，存在商品、订单、采购这3个服务，它们的主数据部分结构表如下。

DawnSql完美超越微服务

核心思想：分而治之，将一个应用拆分成多个松耦合的服务，这些服务之间通过某种协议（REST、RPC等）进行互相协作，其中一个关键点就是各服务之间的松耦合，各服务之间通过一种“标准”的协议进行沟通，不需要理解对方服务的实现逻辑、实现方式，只要在对方不影响自己所提供的服务功能即可。