精华内容
下载资源
问答
  • #资源达人分享计划#
  • #资源达人分享计划#
  • 使用spring cloud代建完整的分布式微服务架构,包括spring security oauth2权限控制,docker,config动态修改配置文件,eureka服务发现,zuul路由,实现服务服务之间的调用。等等
  • 分布式微服务架构体系详解

    万次阅读 多人点赞 2018-07-10 23:30:02
    虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题,但只要我们了解这些问题,并找到解法,就会有种拨开云雾的感觉。 微服务架构也不是完美的,世上没有完美的架构,微服务架构也是随着业务、团队成长而...

    课程介绍

    微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建,或者当现有架构已到达瓶颈需要进行架构演进时,很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题,但只要我们了解这些问题,并找到解法,就会有种拨开云雾的感觉。

    微服务架构也不是完美的,世上没有完美的架构,微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务,每个服务是分库的,通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。

    本课程会一一解开微服务架构下分布式场景的问题,以及通过对于一些分布式技术的原理、模型和算法的介绍,来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且,本课程通过对分布式问题的体系化梳理,结合一些方案的对比选型,可以让工程师们一览微服务的知识图谱。

    注:为了方便初学者理解微服务实践,以及掌握怎样在微服务中使用 DDD(Domain-Driven Design)思想,在本课程第 05 课中讲解了 Demo 示例,该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的,Microservice 代码详见这里Gateway 代码详见这里

    专家推荐

    近年来随着互联网的快速发展,尤其是移动互联网以及云计算的迅猛发展,对于软件交付与迭代速度和效率的要求在不断提高。微服务架构凭借其简单清晰、灵活可扩展、独立部署等优势,越来越成为了分布式架构中的主流。相关的书籍和课程也层出不穷,但更多还是集中在基本理论介绍和一个简单的示例上。本系列课程内容融合了作者多年的实践经验,将微服务架构下的一些经典的分布式问题和场景逐一展开,结合最新的技术潮流,理论结合实际,深入剖析讲解,并且给出了很多对于具体实践选型非常有益的建议。可以说,该课程内容融合了作者从阿里巴巴到创业公司这一路走来所积累的精华,是微服务及分布式领域难得的佳作。

    ——阿里巴巴技术专家,荣博

    作者介绍

    李静瑶,2011 年毕业于中南大学(校优秀毕业生、优秀学生干部),毕业后入职阿里巴巴集团,在职期间主要负责淘宝网营销产品线的研发工作,曾担任试用中心产品线 PM。2015 年开始,在终点网络科技公司担任后端架构师,以及参与 Android、iOS 等客户端研发。现就职于赤金信息科技有限公司,担任 CTO 职位。从零搭建基于 Docker 容器技术的微服务分布式企业集群,深度的 DDD 思想践行者。个人博客:https://blog.csdn.net/lijingyao8206/

    课程内容

    导读:微服务架构下的分布式概览

    微服务架构的演变

    微服务是一种服务间松耦合的、每个服务之间高度自治并且使用轻量级协议进行通信的可持续集成部署的分布式架构体系。这一句包含了微服务的特点,微服务架构和其他架构有什么区别?以下对比一些常见的架构。

    单体架构

    单体架构是最简单的软件架构,常用于传统的应用软件开发以及传统 Web 应用。传统 Web 应用,一般是将所有功能模块都打包(jar、war)在一个 Web 容器(JBoss、Tomcat)中部署、运行。随着业务复杂度增加、技术团队规模扩大,在一个单体应用中维护代码,会降低开发效率,即使是处理一个小需求,也需要将所有机器上的应用全部部署一遍,增加了运维的复杂度。

    SOA 架构

    当某一天使用单体架构发现很难推进需求的开发、以及日积月累的技术债时,很多企业会开始做单体服务的拆分,拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一个应用拆成松耦合的多个独立的应用,让应用可以独立部署,有独立的团队进行维护;水平拆分是把一些通用的,会被很多上层服务调用的模块独立拆分出去,形成一个共享的基础服务,这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理,也在一定程度上防止了垂直拆分的重复造轮子。

    SOA 也叫面向服务的架构,从单体服务到 SOA 的演进,需要结合水平拆分及垂直拆分。SOA 强调用统一的协议进行服务间的通信,服务间运行在彼此独立的硬件平台但是需通过统一的协议接口相互协作,也即将应用系统服务化。举个易懂的例子,单体服务如果相当于一个快餐店,所有的服务员职责都是一样的,又要负责收银结算,又要负责做汉堡,又要负责端盘子,又要负责打扫,服务员之间不需要有交流,用户来了后,服务员从前到后负责到底。SOA 相当于让服务员有职责分工,收银员负责收银,厨师负责做汉堡,保洁阿姨负责打扫等,所有服务员需要用同一种语言交流,方便工作协调。

    微服务和 SOA

    微服务也是一种服务化,不过其和 SOA 架构的服务化概念也是有区别的,可以从以下几个关键字来理解:

    • 松耦合:每个微服务内部都可以使用 DDD(领域驱动设计)的思想进行设计领域模型,服务间尽量减少同步的调用,多使用消息的方式让服务间的领域事件来进行解耦。
    • 轻量级协议:Dubbo 是 SOA 的开源的标准实现之一,类似的还有像 gRPC、Thrift 等。微服务更倾向于使用 Restful 风格的 API,轻量级的协议可以很好地支持跨语言开发的服务,可能有的微服务用 Java 语言实现,有的用 Go 语言,有的用 C++,但所有的语言都可以支持 Http 协议通信,所有的开发人员都能理解 Restful 风格 API 的含义。
    • 高度自治和持续集成:从底层的角度来说,SOA 更加倾向于基于虚拟机或者服务器的部署,每个应用都部署在不同的机器上,一般持续集成工具更多是由运维团队写一些 Shell 脚本以及提供基于共同协议(比如 Dubbo 管理页面)的开发部署页面。微服务可以很好得和容器技术结合,容器技术比微服务出现得晚,但是容器技术的出现让微服务的实施更加简便,目前 Docker 已经成为很多微服务实践的基础容器。因为容器的特色,所以一台机器上可以部署几十个、几百个不同的微服务。如果某个微服务流量压力比其他微服务大,可以在不增加机器的情况下,在一台机器上多分配一些该微服务的容器实例。同时,因为 Docker 的容器编排社区日渐成熟,类似 Mesos、Kubernetes 及 Docker 官方提供的 Swarm 都可以作为持续集成部署的技术选择。

    其实从架构的演进的角度来看,整体的演进都是朝着越来越轻量级、越来越灵活的应用方向发展,甚至到近两年日渐成熟起来的 Serverless(无服务)架构。从单体服务到分层的服务,再到面向服务、再到微服务甚至无服务,对于架构的挑战是越来越大。

    微服务架构和分布式

    微服务架构属于分布式系统吗?答案是肯定的。微服务和 SOA 都是典型的分布式架构,只不过微服务的部署粒度更细,服务扩展更灵活。

    理解微服务中的分布式

    怎样理解微服务中的分布式?举个招聘时某同学来面试的例子。A 同学说,目前所在公司在做从单应用到微服务架构迁移,已经差不多完成了。提到微服务感觉就有话题聊了,于是便问“是否可以简单描述下服务拆分后的部署结构、底层存储的拆分、迁移方案?”。于是 A 同学说,只是做了代码工程结构的拆分,还是原来的部署方式,数据库还是那个库,所有的微服务都用一个库,分布式事务处理方式是“避免”,尽量都同步调用……于是我就跟这位同学友好地微笑说再见了。

    微服务的分布式不仅仅是容器应用层面的分布式,其为了高度自治,底层的存储体系也应该互相独立,并且也不是所有的微服务都需要持久化的存储服务。一个“手机验证码”微服务可能底层存储只用一个 Redis;一个“营销活动搭建页面”微服务可能底层存储只需要一个 MongoDB。

    微服务中的分布式场景除了服务本身需要有服务发现、负载均衡,微服务依赖的底层存储也会有分布式的场景:为了高可用性和性能需要处理数据库的复制、分区,并且在存储的分库情况下,微服务需要能保证分布式事务的一致性。

    课程背景

    微服务架构的技术体系、社区目前已经越来越成熟,所以在初期选择使用或者企业技术体系转型微服务的时候,需要了解微服务架构中的分布式的问题:

    • 在所有服务都是更小单元的部署结构时,一个请求需要调动更多的服务资源,怎样获得更好的性能?
    • 当业务规模增大,需要有地理分布不同的微服务集群时,其底层的数据存储集群是多数据中心还是单数据集群?
    • 数据存储如何进行数据复制?
    • 业务数据达到大数据量时怎样进行数据的分区?
    • 分布式事务怎样保证一致性?
    • 不同程度的一致性有什么差别?
    • 基于容器技术的服务发现怎么处理?
    • 应该用哪些 RPC 技术,用哪些分布式消息队列来完成服务通信和解耦?
    • 那么多的分布式技术框架、算法、服务应该选哪个才适合企业的业务场景?

    本课程从微服务不得不面对和解决的分布式问题出发,包含分布式技术的一系列理论以及架构模型、算法的介绍,同时结合技术选型和实践应用,提供一系列解决方案的梳理。相信阅读完整个课程,你会对微服务的分布式问题有个系统地理解。本课程会对微服务的分布式场景问题一一击破,为你提供解决思路。

    课程内容

    本课程示例代码地址如下:

    分布式系统的问题

    • 引出分布式系统的可能问题:节点故障、网络延迟,结合错误检测的可行方案进行介绍;
    • 分布式中的时间和顺序的问题,以及标量时钟和向量时钟的实现。

    分布式数据存储

    • 分布式数据存储的技术选型、关系型数据库以及一些流行的 NoSQL 技术介绍(MongoDB、Redis、Neo4j 及 Cassandra 等);
    • 分布式存储技术使用的数据结构,了解底层数据存储原理(HashTable、SSTable、LSMTree、BTree 等);
    • 各个存储方案使用的场景以及对比。

    数据复制

    • 对于大规模存储集群,需要进行数据库的复制、排除单点故障;
    • 数据复制的模型和实现以及几种复制日志的实现方式;
    • 主备同步、主主复制、多数据中心的数据复制方案;
    • 数据复制中的读写一致性问题以及写冲突问题的解决;
    • 介绍以 MySQL 为例延伸集群数据复制方案。

    数据分区

    • 当单个领域模型维度的数据已经到一定规模时,需要进行数据分区,减轻单库压力。数据分区和分表又有哪些不同?数据分区可以如何实现?
    • 以 MySQL 的分区策略为例介绍不同分区策略的实现。
    • 数据分区后,请求的路由有哪些解决方案?会展开介绍不同的方案又有什么差别。

    服务发现和服务通信

    • 基于容器技术的微服务体系,怎样选择服务发现、负载均衡的技术实现?不同的服务发现的技术有什么区别,如何选型?
    • 为了达到松耦合的目的以及基于 DDD 思想,微服务之间减少服务调用可以通过哪些技术实现?API Gateway 可以用哪些技术框架实现?远程调用可以有哪些技术框架?怎样提高同步通信的性能?
    • 分布式的消息队列都有哪些开源、商业实现?应该怎样选择适合的消息队列?
    • 使用 DDD 思想应该如何应对服务通信,如何在实践中应用 DDD?

    分布式存储集群的事务

    • 理解分布式中的事务以及本地事务的基础概念;
    • 分布式存储的隔离级别以及各个 DB 支持的隔离方案的实现原理;
    • 以 MySQL InnoDB 中的 MVCC 为例看并发控制的在 MySQL 的实现,学习存储系统对于分布式事务的实现思想。

    分布式一致性

    • 了解分布式系统的一致性有哪些问题以及一致性的几种实现程度的模型:线性一致性(强一致性)、顺序一致性及因果一致性、最终一致性;
    • 分布式一致性相关的理论 CAP(CA、CP、AP 的相关算法)的介绍以及适合用于哪些实践;
    • 介绍 FLP 不可能结果,以及 BASE 理论。

    分布式事务实践

    • 了解微服务中分布式事务的问题;
    • 介绍强一致性的实践:二阶段、三阶段。2PC、3PC 的优缺点和限制,XA 协议的介绍和实践方案,以及最终一致性实践:TCC 模型和实践方案;
    • 分布式锁的实现模型和实践方案;
    • 基于微服务下的分布式事务实践案例分析。

    共识问题

    • 了解为什么分布式场景下有共识问题;
    • 介绍共识算法和全局消息广播的实现,公式算法的基础:leader 选举和 quorum 算法,以及一些已实现的算法的介绍和对比:VSR、Raft、Paxos、ZAB;
    • 共识算法在微服务体系的应用场景介绍:服务发现、一致性 kv 存储(Etcd、Zk)以及技术的选型如何权衡一致性的追求和性能。

    架构设计

    • 了解了很多分布式的问题和解决方案之后,回归微服务架构模型、技术选型、再回顾下微服务的弊端和特点;
    • 微服务体系的架构要素分析:安全、伸缩性、性能、可用性、扩展性;
    • 结合团队、业务场景的 DDD 实践和总结。

    课程寄语

    • 如果你是一位开发工程师,相信阅读完本系列课程,将会了解很多分布式系统的理论知识,同时也会理解一些分布式存储、中间件技术的原理,对工作中的分布式架构会有体系化的清晰认知。
    • 如果你是一位架构师,本系列课程提供了对于分布式系统问题的全面梳理,以及一些技术背后的理论,结合实践和目前业界先进的方案,对于技术选型和架构搭建提供了参考。

    点击了解更多《案例上手分布式微服务架构》

    第01课:分布式系统的问题

    前言

    无论是 SOA 或者微服务架构,都是必须要面对和解决一些分布式场景下的问题。如果只是单服务、做个简单的主备,那么编程则会成为一件简单幸福的事,只要没有 bug,一切都会按照你的预期进行。然而在分布式系统中,如果想当然的去按照单服务思想编程和架构,那可能会收获很多意想不到的“惊喜”:网络延迟导致的重复提交、数据不一致、部分节点挂掉但是任务处理了一半等。在分布式系统环境下编程和在单机器系统上写软件最大的差别就是,分布式环境下会有很多很“诡异”的方式出错,所以我们需要理解哪些是不能依靠的,以及如何处理分布式系统的各种问题。

    理想和现实

    微服务架构跟 SOA 一样,也是服务化的思想。在微服务中,我们倾向于使用 RESTful 风格的接口进行通信,使用 Docker 来管理服务实例。我们的理想是希望分布式系统能像在单个机器中运行一样,就像客户端应用,再坏的情况,用户只要一键重启就可以重新恢复,然而现实是我们必须面对分布式环境下的由网络延迟、节点崩溃等导致的各种突发情况。

    在决定使用分布式系统,或者微服务架构的时候,往往是因为我们希望获得更好的伸缩性、更好的性能、高可用性(容错)。虽然分布式系统环境更加复杂,但只要能了解分布式系统的问题以及找到适合自己应用场景的方案,便能更接近理想的开发环境,同时也能获得伸缩性、性能、可用性。

    分布式系统的可能问题

    分布式系统从结构上来看,是由多台机器节点,以及保证节点间通信的网络组成,所以需要关注节点、网络的特征。

    (1)部分失败

    在分布式环境下,有可能是节点挂了,或者是网络断了,如下图:

    part failure

    如果系统中的某个节点挂掉了,但是其他节点可以正常提供服务,这种部分失败,不像单台机器或者本地服务那样好处理。单机的多线程对象可以通过机器的资源进行协调和同步,以及决定如何进行错误恢复。但在分布式环境下,没有一个可以来进行协调同步、资源分配以及进行故障恢复的节点,部分失败一般是无法预测的,有时甚至无法知道请求任务是否有被成功处理。

    所以在开发需要进行网络通讯的接口时(RPC 或者异步消息),需要考虑到部分失败,让整个系统接受部分失败并做好容错机制,比如在网络传输失败时要能在服务层处理好,并且给用户一个好的反馈。

    (2)网络延迟

    网络是机器间通信的唯一路径,但这条唯一路径并不是可靠的,而且分布式系统中一定会存在网络延迟,网络延迟会影响系统对于“超时时间”、“心跳机制”的判断。如果是使用异步的系统模型,还会有各种环节可能出错:可能请求没有成功发出去、可能远程节点收到请求但是处理请求的进程突然挂掉、可能请求已经处理了但是在 Response,可能在网络上传输失败(如数据包丢失)或者延迟,而且网络延迟一般无法辨别。

    即使是 TCP 能够建立可靠的连接,不丢失数据并且按照顺序传输,但是也处理不了网络延迟。对于网络延迟敏感的应用,使用 UDP 会更好,UDP 不保证可靠传输,也不会丢失重发,但是可以避免一些网络延迟,适合处理音频和视频的应用。

    (3)没有共享内存、锁、时钟

    分布式系统的节点间没有共享的内存,不应理所当然认为本地对象和远程对象是同一个对象。分布式系统也不像单机器的情况,可以共享同一个 CPU 的信号量以及并发操作的控制;也没有共享的物理时钟,无法保证所有机器的时间是绝对一致的。时间的顺序是很重要的,夸张一点说,假如对于一个人来说,从一个时钟来看是 7 点起床、8 点出门,但可能因为不同时钟的时间不一致,从不同节点上来看可能是 7 点出门、8 点起床。

    在分布式环境下开发,需要我们能够有意识地进行问题识别,以上只是举例了一部分场景和问题,不同的接口实现,会在分布式环境下有不同的性能、扩展性、可靠性的表现。下面会继续上述的问题进行探讨,如何实现一个更可靠的系统。

    概念和处理模型

    对于上述分布式系统中的一些问题,可以针对不同的特征做一些容错和处理,下面主要看一下错误检测以及时间和顺序的处理模型。在实际处理中,一般是综合多个方案以及应用的特点。

    错误检测

    对于部分失败,需要一分为二的看待。

    节点的部分失败,可以通过增加错误检测的机制,自动检测问题节点。在实际的应用中,比如有通过 Load Balancer,自动排除问题节点,只将请求发送给有效的节点。对于需要有 Leader 选举的服务集群来说,可以引入实现 Leader 选举的算法,如果 Leader 节点挂掉了,其余节点能选举出新的 Leader。实现选举算法也属于共识问题,在后续文章中会再涉及到几种算法的实现和应用。

    网络问题:由于网络的不确定性,比较难说一个节点是否真正的“在工作”(有可能是网络延迟导致的错误),通过添加一些反馈机制可以在一定程度确定节点是否正常运行,比如:

    • 健康检查机制,一般是通过心跳检测来实现的,比如使用 Docker 的话,Consul、Eureka 都有健康检查机制,当发送心跳请求发现容器实例已经无法回应时,可以认为服务挂掉了,但是却很难确认在这个 Node/Container 中有多少数据被正确的处理了。
    • 如果一个节点的某个进程挂了,但是整个节点还可以正常运行。在使用微服务体系中是比较常见的,一台机器上部署着很多容器实例,其中个容器实例(即相当于刚才描述挂掉的进程)挂掉了,可以有一个方式去通知其他容器来快速接管,而不用等待执行超时。比如 Consul 通过 Gossip 协议进行多播,关于 Consul,可以参考这篇 Docker 容器部署 Consul 集群 内容。在批处理系统中,HBase 也有故障转移机制。

    在实际做错误检测处理时,除了需要 节点、容器 做出积极的反馈,还要有一定的重试机制。重试的实现可以基于网络传输协议,如使用 TCP 的 RTT;也可以在应用层实现,如 Kafka 的 at-least-once 的实现。基于 Docker 体系的应用,可以使用 SpringCloud 的 Retry,结合 Hytrix、Ribbon 等。对于需要给用户反馈的应用,不太建议使用过多重试,根据不同的场景进行判断,更多的时候需要应用做出积极的响应即可,比如用户的“个人中心页面”,当 User 微服务挂了,可以给个默认头像、默认昵称,然后正确展示其他信息,而不是反复请求 User 微服务。

    时间和顺序

    在分布式系统中,时间可以作为所有执行操作的顺序先后的判定标准,也可以作为一些算法的边界条件。在分布式系统中决定操作的顺序是很重要的,比如对于提供分布式存储服务的系统来说,Repeated Read 以及 Serializable 的隔离级别,需要确定事务的顺序,以及一些事件的因果关系等。

    物理时钟

    每个机器都有两个不同的时钟,一个是 time-of-day,即常用的关于当前的日期、时间的信息,例如,此时是 2018 年 6 月 23 日 23:08:00,在 Java 中可以用 System.currentTimeMillis() 获取;另一个是 Monotonic 时钟,代表着单调递增的时间,一般是测量时间间距,在 Java 中调用 System.nanoTime() 可以获得 Monotonic 时间,常常用于测量一个本地请求的返回时间,比如 Apache commons 中的 StopWatch 的实现。

    在分布式环境中,一般不会使用 Monotonic,测量两台不同的机器的 Monotonic 的时间差是无意义的。

    不同机器的 time-of-day 一般也不同,就算使用 NTP 同步所有机器时间,也会存在毫秒级的差,NTP 本身也允许存在前后 0.05% 的误差。如果需要同步所有机器的时间,还需要对所有机器时间值进行监控,如果一个机器的时间和其他的有很大差异,需要移除不一致的节点。因为能改变机器时间的因素比较多,比如无法判断是否有人登上某台机器改变了其本地时间。

    虽然全局时钟很难实现,并且有一定的限制,但基于全局时钟的假设还是有一些实践上的应用。比如 Facebook Cassandra 使用 NTP 同步时间来实现 LWW(Last Write Win)。Cassandra 假设有一个全局时钟,并基于这个时钟的值,用最新的写入覆盖旧值。当然时钟上的最新不代表顺序的最新,LWW 区分不了实际顺序;另外还有如 Google Spanner 使用 GPS 和原子时钟进行时间同步,但节点之间还是会存在时间误差。

    逻辑时钟

    在分布式系统中,因为全局时钟很难实现,并且像 NTP 同步过程,也会受到网络传输时间的影响,一般不会使用刚才所述的全局同步时间,当然也肯定不能使用各个机器的本地时间。对于需要确认操作执行顺序的时候,不能简单依赖一个基于 time-of-day 的 timestamps,所以需要一个逻辑时钟,来标记一些事件顺序、操作顺序的序列号。常见的方式是给所有操作加上递增的计数器。

    这种所有操作都添加一个全局唯一的序列号的方式,提供了一种全局顺序的保证,全局顺序也包含了因果顺序一致的概念。关于分布式一致性的概念和实现会在后续文章详细介绍,我们先将关注点回归到时间和顺序上。下面看两种典型的逻辑时钟实现。

    (1)Lamport Timestamps

    Lamport timestamps 是 Leslie Lamport 在 1978 年提出的一种逻辑时钟的实现方法。Lamport Timestamps 的算法实现,可以理解为基于每个节点的一对值(NodeId,Counter)的全局顺序的同步。在集群中的每个节点(Node)都有一个唯一标识,并且每个 Node 都持有一个本地的对于所有操作顺序的一个 Counter(计数器)。

    Lamport 实现的核心思想就是把事件分成三类(节点内处理的事件、发送事件、接收事件):

    • 如果一个节点处理一个事件,节点 counter +1。
    • 如果是发送一个消息事件,则在消息中带上 counter 值。
    • 如果是接收一个消息事件,则更新 counter = max(本地 counter,接收的消息中带的 counter) +1。

    简单画了个示例如下图:

    lamport timestamps example

    初始的 counter 都是 0,在 Node1 接收到请求,处理事件时 counter+1(C:1表示),并且再发送消息带上 C:1。

    在 Node1 接受 ClientA 请求时,本地的 Counter=1 > ClientA 请求的值,所以处理事件时 max(1,0)+1=2(C:2),然后再发送消息,带上 Counter 值,ClientA 更新请求的最大 Counter 值 =2,并在下一次对 Node2 的事件发送时会带上这个值。

    这种序列号的全局顺序的递增,需要每次 Client 请求持续跟踪 Node 返回的 Counter,并且再下一次请求时带上这个 Counter。lamport 维护了全局顺序,但是却不能更好的处理并发。在并发的情况下,因为网络延迟,可能导致先发生的事件被认为是后发生的事件。如图中红色的两个事件属于并发事件,虽然 ClientB 的事件先发出,但是因为延迟,所以在 Node 1 中会先处理 ClientA,也即在 Lamport 的算法中,认为 Node1(C:4) happens before Node1(C:5)。

    Lamport Timestamps 还有另一种并发冲突事件:不同的 NodeId,但 Counter 值相同,这种冲突会通过 Node 的编号的比较进行并发处理。比如 Node2(C:10)、Node1(C:10) 是两个并发事件,则认为 Node2 的时间顺序值 > Node1 的序列值,也就认为 Node1(C:10) happens before Node2(C:10)。

    所以可见,Lamport 时间戳是一种逻辑的时间戳,其可以表示全局的执行顺序,但是无法识别并发,以及因果顺序,并发情况无法很好地处理 偏序

    (2)Vector Clock

    Vector Clock 又叫向量时钟,跟 Lamport Timestamps 比较类似,也是使用 SequenceNo 实现逻辑时钟,但是最主要的区别是向量时钟有因果关系,可以区分两个并发操作,是否一个操作依赖于另外一个。

    Lamport Timestamps 通过不断把本地的 counter 更新成公共的 MaxCounter 来维持事件的全局顺序。Vector Clock 则各个节点维持自己本地的一个递增的 Counter,并且会多记录其他节点事件的 Counter。通过维护了一组 [NodeId,Counter] 值来记录事件的因果顺序,能更好得识别并发事件,也即,Vector Clock 的 [NodeId,Counter] 不仅记录了本地的,还记录了其他 Node 的 Counter 信息。

    Vector Clock 的 [NodeId,Counter] 更新规则:

    • 如果一个节点处理一个事件,节点本地的逻辑时钟的 counter +1。
    • 当节点发送一个消息,需要包含所有本地逻辑时钟的一组 [NodeId,Counter] 记录值。
    • 接受一个事件消息时, 更新本地逻辑时钟的这组 [NodeId,Counter] 值:
      • 让这组 [NodeId,Counter] 值中每个值都是 max(本地 counter,接收的消息中的counter)。
      • 本地逻辑时钟 counter+1。

    如下图简单示意了 Vector Clock 的时间顺序记录:

    Vector clock example

    三个 Node,初始 counter 都是 0。NodeB 在处理 NodeC 的请求时,记录了 NodeC 的 Counter=1,并且处理事件时,本地逻辑时钟的 counter=0+1,所以 NodeB 处理事件时更新了本地逻辑时钟为 [B:1,C:1]。在事件处理时,通过不断更新本地的这组 Counter,就可以根据一组 [NodeId,Counter] 值来确定请求的因果顺序了,比如对于 NodeB,第二个处理事件 [A:1,B:2,C:1] 早于第三个事件:[A:1,B:3,C:1]。

    在数值冲突的时候,如图中红色箭头标记的。NodeC 的 [A:2,B:2,C:3] 和 NodeB[A:3,B:4,C:1]。C:3 > C:1、B:2 < B:4,种情况认为是没有因果关系,属于同时发生。

    Vector Clock 可以通过各个节点的时间序列值的一组值,识别两个事件的先后顺序。Vector 提供了发现数据冲突的方式,但是具体怎样解决冲突需要由发现冲突的节点决定,比如可以将并发冲突抛给 Client 决定,或者用 Quorum-NRW 算法进行读取修复(Read Repair)。

    Amazon Dynamo 就是通过 Vector Clock 来做并发检测的一个很好的分布式存储系统的例子。对于复制节点的数据冲突使用了 Quorum NRW 决议,以及读修复(Read Repair)处理最新更新数据的丢失,详细实现可以参考这篇论文 Dynamo: Amazon’s Highly Available Key-value Store ,Dynamo 是典型的高可用、可扩展的,提供弱一致性(最终一致性)保证的分布式 K-V 数据存储服务。后续文章再介绍 Quorums 算法时,也会再次提到。Vector Clock 在实际应用中,还会有一些问题需要处理,比如如果一个上千节点的集群,那么随着时间的推移,每个 Node 将需要记录大量 [NodeId,Counter] 数据。Dynamo 的解决方案是通过添加一个 timestamp 记录每个 Node 更新 [NodeId,Counter] 值的时间,以及一个设定好的阈值,比如说阈值是 10,那么本地只保存最新的 10 个 [NodeId,Counter] 组合数据。

    小结

    本文引出了一些分布式系统的常见问题以及一些基础的分布式系统模型概念,微服务的架构目前已经被更广泛得应用,但微服务面临的问题其实也都是经典的分布式场景的问题。本文在分布式系统的问题中,主要介绍了关于错误检测以及时间和顺序的处理模型。

    关于时间和顺序的问题处理中,没有一个绝对最优的方案,Cassandra 使用了全局时钟以及 LWW 处理顺序判定;Dynamo 使用了 Vector clock 发现冲突,加上 Quorum 算法处理事件并发。这两个存储系统都有很多优秀的分布式系统设计和思想,在后续文章中会更详细的介绍数据复制、一致性、共识算法等。

    参考资料

    点击了解更多《案例上手分布式微服务架构》

    第02课:数据存储

    前言

    微服务架构下,很适合用 DDD(Domain-Drive Design)思维来设计各个微服务,使用领域驱动设计的理念,工程师们的关注点需要从 CRUD 思维中跳出来,更多关注通用语言的设计、实体以及值对象的设计。至于数据仓库,会有更多样化的选择。分布式系统中数据存储服务是基础,微服务的领域拆分、领域建模可以让数据存储方案的选择更具灵活性。

    不一定所有的微服务都需要有一个底层的关系型数据库作为实体对象实例的存储。以一个简单的电商系统为例:“用户微服务”和“商品微服务”都分别需要关系型数据库存储结构化的关联数据。但比如有一个“关联推荐微服务“需要进行用户购买、加购物车、订单、浏览等多维度的数据整合,这个服务不能将其他所有订单,用户、商品等服务的数据冗余进来,这种场景可以考虑使用图形数据库。又比如有一个“验证码微服务”,存储手机验证码、或者一些类似各种促销活动发的活动码、口令等,这种简单的数据结构,而且读多写少,不需长期持久化的场景,可以只使用一个 K-V(键值对)数据库服务。

    本文先简单介绍下适合微服务架构体系的一些分布式数据存储方案,然后深入介绍下这些存储服务的数据结构实现,知其然知其所以然。后续文章会继续介绍分布式数据存储的复制、分区。

    数据存储类型介绍

    不同的数据存储引擎有着不同的特征,也适合不同的微服务。在做最初的选型时,需要先根据对整体业务范围的判断,选择尽量普适于大多数微服务的存储。例如,初创型企业,需要综合考虑成本节约以及团队的知识掌握度等问题,MySQL 是比较常见的选择,电商类型的微服务应用更适合 InnoDB 引擎(事务、外键的支持、行锁的性能),虽然 InnoDB 的读性能会比 MyISAM 差,但是读场景有很多可以优化的方案,如搜索引擎、分布式缓存、本地缓存等。

    下面会以不同场景为例,整理一部分常用的数据存储引擎,实际的企业应用中会针对不同场景、服务特征综合使用多种存储引擎。

    关系型数据库

    存储结构化数据,以及需要更多维度关联,需要给用户提供丰富的实时查询场景时,应该使用关系型数据库。从开源以及可部署高可用性集群的方面来看,MySQLPostgreSQL 都是不错的选择。PostgreSQL 的历史更为悠久,两者都有很多大互联网公司如 Twitter、Facebook、Yahoo 等部署着大规模分布式存储集群,集群的复制、分区方案会在后续文章详细介绍。

    NoSQL

    NoSQL 即 Not Only SQL,其概念比关系型数据库更新,NoSQL 为数据的查询提供了更灵活、丰富的场景。下面简单列举了一些 NoSQL 数据库及其应用场景。工程师不一定需要掌握所有的 NoSQL 数据库的细节,对于不同的领域模型的设计,能有更多的灵感会更好。

    KeyValue 存储

    KeyValue 可以说是 NoSQL 中比较简单的一族,大多数操作只有 get()、put(),基础的数据格式也都是简单的 Key-Value。

    目前比较流行的键值存储服务有 RedisMemcached 以及上篇文中提到的 Dynamo。其中 Redis 有 Redis Cluster 提供了支持 Master 选举的高可用性集群。Dynamo 也有分布式高可用集群,基于 Gossip 协议的节点间故障检测,以及支持节点暂时、永久失效的故障恢复,这两者为了保证高可用以及性能,牺牲了强一致性的保证,但是都支持最终一致性。Memcached 提供了高性能的纯基于内存的 KV 存储,并且提供 CAS 操作来支持分布式一致性,但 Memcached 没有官方提供的内置集群方案,需要使用一些代理中间件,如 Magento 来部署集群。

    在实际选择时,如果需要高速缓存的性能并且可以接受缓存不被命中的情况,以及可以接受 Memcached 服务实例重启后数据全部丢失,可以选择 Memcached。用 Memcached 做二级缓存来抗住一些高 QPS 的请求是很适合的,比如对于一些 Hot 商品的信息,可以放到 Memcached 中,缓解 DB 压力。

    如果既需要有数据持久化的需求,也希望有好的缓存性能,并且会有一些全局排序、数据集合并等需求,可以考虑使用 Redis。Redis 除了支持 K-V 结构的数据,还支持 list、set、hash、zset 等数据结构,可以使用 Redis 的 SET key value 操作实现一些类似手机验证码的存储,对于需要按照 key 值排序的 kv 数据可以用 ZADD key score member。利用 Redis 的单线程以及持久化特性,还可以实现简单的分布式锁,具体可以参考笔者之前写的这篇 《基于 Redis 实现分布式锁实现》 文章。

    文档型数据库

    面向文档的数据库可以理解成 Value 是一个文档类型数据的 KV 存储,如果领域模型是个文件类型的数据、并且结构简单,可以使用文档型数据库,比较有代表性的有 MongoDBCouchDB。MongoDB 相比可用性,更关注一致性,Value 存储格式是内置的 BSON 结构,CouchDB 支持内置 JSON 存储,通过 MVCC 实现最终一致性,但保证高可用性。

    如果你需要的是一个高可用的多数据中心,或者需要 Master-Master,并且需要能承受数据节点下线的情况,可以考虑用 CouchDB。如果你需要一个高性能的,类似存储文档类型数据的 Cache 层,尤其写入更新比较多的场景,那就用 MongoDB 吧。另外,2018 年夏天可以期待下,MongoDB 官方宣布即将发布的 4.0 版本,支持跨副本集(Replica set)的 ACID 事务,4.2 版本将支持跨集群的事务,详情可以关注 MongoDB 的 Beta 计划

    图形数据库

    在现实世界中,一个图形的构成主要有“点”和“边”,在图形数据库中也是一样,只不过点和边有了抽象的概念,“点”代表着一个实体、节点,“边”代表着关系。开源的 Neo4j 是可以支持大规模分布式集群的图形数据库。一般被广泛用于道路交通应用、SNS 应用等,Neo4j 提供了独特的查询语言 CypherQueryLanguage

    为了直观了解 Neo4j 的数据结构,可以看下这个示例(在运行 Neo4j 后,官方的内置数据示例),图中绿色节点代表“Person”实体,中间的有向的剪头连线就是代表节点之间的关系“Knows”。

    eo4j example query

    通过以下 CQL 语句就可以查询所有 Knows、Mike 的节点以及关系:

    MATCH p=()-[r:KNOWS]->(g) where g.name ='Mike' RETURN p LIMIT 25 

    neo4j example res

    以上只是单个点和单维度关系的例子,在实际中 Person 实体间可能还存在 Follow、Like 等关系,如果想找到 Knows 并且 Like Mike,同时又被 Jim Follow 的 Person。在没有图形数据库的情况下,用关系型数据库虽然也可以查询各种关联数据,但这需要各种表 join、union,性能差而且需要写很多 SQL 代码,用 CQL 只要一行即可。

    在 SpringBoot 工程中,使用 Springboot-data 项目,可以很简单地和 Neo4j 进行集成,官方示例可以直接 checkout 查看 java-spring-data-neo4j

    文档数据库一般都是很少有数据间的关联的,图形数据库就是为了让你快速查询一切你想要的关联。如果想更进一步了解 Neo4j,可以直接下载 Neo4j 桌面客户端,一键启动、然后在浏览器输入 http://localhost:7474/browser/ 就可以用起来了。

    列族数据库

    列族数据库一般都拥有大规模的分布式集群,可以用来做灵活的数据分析、处理数据报表,尤其适合写多读少的场景。列族和关系型数据库的差别,从应用角度来看,主要是列族没有 Schema 的概念,不像关系型数据库,需要建表的时候定义好每个列的字段名、字段类型、字段大小等。

    列族数据库中目前比较广泛应用的有 Hbase,Hbase 是基于 Google BigTable 设计思想的开源版。BigTable 虽然没开源,但是其论文 Bigtable: A Distributed Storage System for Structured Data 提供了很多设布式列族 DB 的实现逻辑。另外 Facebook Cassandra 也是一个写性能很好的列族数据库,其参考了 Dynamo 的分布式设计以及 BigTable 的数据存储结构,支持最终一致性,适合跨地域的多数据中心的分布式存储。不过 Cassandra 中文社区相对薄弱,国内还是 Hbase 的集群更为广泛被部署。

    存储服务的数据结构

    在了解了一些分布式数据存储的产品之后,为了能更深地理解,下面会对分布式存储引擎的一些常用数据结构做进一步介绍。一台计算机,可以作为数据存储的地方就是内存、磁盘。分布式的数据存储就是将各个计算机(Node)的内存和磁盘结合起来,不同类型的存储服务使用的核心数据结构也会不同。

    哈希表

    哈希表是一种比较简单 K-V 存储结构,通过哈希函数将 Key 散列开,Key 哈希值相同的 Value 一般会以单链表结构存储。哈希表查找效率很高,常用于内存型存储服务如 Memcached、Redis。Redis 除了哈希表,因为其支持的操作的数据类型很多,所以还有像 Skiplist、SDS、链表等存储结构,并且 Redis 的哈希表结构可以通过自动再哈希进行扩容。

    哈希表一般存储在内存中,随着哈希表数据增多,会影响查询效率,并且内存结构也没法像磁盘那样可以持久化以及进行数据恢复。Redis 默认提供了 RDB 持久化方案,定时持久化数据到 RDB。用 RDB 来做数据恢复、备份是很合适的方案,但是因为其定期执行,所以无法保证恢复数据的一致性、完整性。Redis 还支持另一种持久化方案——基于 AOF(Append Only File) 方式,对每一次写操作进行持久化,AOF 默认不启用,可以通过修改 redis.conf 启用,AOF 增加了 IO 负荷,比较影响写性能,适合需要保证一致性的场景。

    SSTable

    在我们平常在 Linux 上分析日志文件的时候,比如用 grep、cat、tail 等命令,其实可以想象成在 Query 一个持久化在磁盘的 log 文件。我们可以用命令轻松查询以及分析磁盘文件,查询一个记录的时间复杂度是 O(n) 的话(因为要遍历文件),查询两个记录就是 2*O(n),并且如果文件很大,我们没法把文件 load 到内存进行解析,也没法进行范围查询。

    SSTable(Sorted String Table) 就解决了排序和范围查询的问题,SSTable 将文件分成一个一个 Segment(段),不同的 Segment File 可能有相同的值,但每个 Segement File 内部是按照顺序存储的。不过虽然只是将文件分段,并且按照内容顺序(Sorted String)存储可以解决排序,但是查询磁盘文件的效率是很低的。

    为了能快速查询文件数据,可以在内存中附加一个 KV 结构的索引:(key-offset)。key 值是索引的值并且也是有序的,Offset 指向 Segment File 的实际存储位置(地址偏移)。

    如下图简单画了一个有内存 KV 存储的 SSTable 数据结构:

    memtable sstable exm

    这个 k-v 结构的存储结构又叫 Memtable,因为 Memtable 的 key 也是有序的,所以为了实现内存快速检索,Memtable 本身可以使用红黑树、平衡二叉树、skip list 等数据结构来实现。Ps:B-Tree、B+Tree 的结构适合做大于内存的数据的索引存储(如 MySQL 使用 B+ 树实现索引文件的存储),所以其更适合磁盘文件系统,一般不会用来实现 Memtable。

    SSTable 也是有些局限性的,内存的空间是有限的,随着文件数越来越多,查询效率会逐渐降低。为了优化查询,可以将 Segment File 进行合并,减少磁盘 IO,并且一定程度持久化 Memtable(提高内存查询效率)——这就是 LSM-tree(Log-structured Merge-Tree)。LSM-tree 最初由 Google 发布的 Bigtable 的设计论文 提出,目前已经被广泛用于列族数据库如 HBase、Cassandra,并且 Google 的 LevelDB 也是用 LMS-tree 实现,LevelDB 的 Memtable 使用的是 skip list 数据结构。

    这种提供 SSTable 合并、压缩以及定期 flush Memtable 到磁盘的优化,使 LMS-tree 的写入吞吐量高,适合高写场景。下面以 Cassandra 为例介绍下 LMS-tree 的典型数据流。

    (1)Cassandra LMS-tree 写

    数据先写到 Commit Log 文件中(Commit Log 用 WAL 实现)WAL 保证了故障时,可以恢复内存中 Memtable 的数据。

    数据顺序写入 Memtable 中。

    随着 Memtable Size 达到一定阀值或者时间达到阀值时,会 flush 到 SSTable 中进行持久化,并且在 Memtable 数据持久化到 SSTable 之后,SSTables 都是不可再改变的

    后台进程会进行 SSTable 之间的压缩、合并,Cassendra 支持两种合并策略:对于多写的数据可以使用 SizeTiered 合并策略(小的、新的 SSTable 合并到大的、旧的 SSTable 中),对于多读的数据可以使用 Leveled 合并策略(因为分层压缩的 IO 比较多,写多的话会消耗 IO),详情可以参考 when-to-use-leveled-compaction

    (2)Cassandra LMS-tree 读

    先从 Memtable 中查询数据。

    Bloom Filter 中读取 SStable 中数据标记,Bloom Filter 可以简单理解为一个内存的 set 结构,存储着被“删除”的数据,因为刚才介绍到 SSTable 不能改变,所以一些删除之后的数据放到这个 set 中,读请求需要从这个标记着抛弃对象们的集合中读取“不存在”的对象,并在结果中过滤。对于 SSTables 中一些过期的,会在合并时被清除掉。

    从多个 SSTables 中读取数据。

    合并结果集、返回。另外,对于“更新”操作,是直接更新在 Memtable 中的,所以结果集会优先返回 Memtable 中的数据。

    BTree、B + Tree

    BTree 和 B + Tree 比较适合磁盘文件的检索,一般用于关系型数据库的索引数据的存储,如 Mysql-InnoDB、PostgreSQL。为了提高可用性,一般 DB 中都会有一个 append-only 的 WAL(一般也叫 redo-log)用来恢复数据,比如 MySQL InnoDB 中用 binlog 记录所有写操作,binlog 还可以用于数据同步、复制。

    使用 Btree、B+Tree 的索引需要每个数据都写两次,一次写入 redo-log、一次将数据写入 Tree 中对应的数据页(Page)里。LMS-tree 结构其实需要写入很多次,因为会有多次的数据合并(后台进程),因为都是顺序写入,所以写入的吞吐量更好,并且磁盘空间利用率更高。而 B 树会有一些空的 Page 没有数据写入、空间利用率较低。读取的效率来说,Btree 更高,同样的 key 在 Btree 中存储在一个固定的 Page 中,但是 LSM-tree 可能会有多个 Segment File 中存储着同个 Key 对应的值。

    小结

    本篇介绍了很多分布式存储服务,在实际的开发中,需要结合领域服务的特点选择。有的微服务可能只需要一个Neo4j,有的微服务只需要 Redis。微服务的架构应该可以让领域服务的存储更加灵活和丰富,在选择时可以更加契合领域模型以及服务边界。

    文章后半部分介绍了部分存储服务的数据结构。了解了实现的数据结构可以让我们更深刻理解存储引擎本身。从最简单的 append-only 的文件存储,再到哈希表、SSTable、BTree,基本涵盖了目前流行的存储服务的主流数据结构。如果想深入理解 LSM-tree,可以读一下 BigTable 的那篇经典论文。

    除了数据库服务,像 Lucene 提供了全文索引的搜索引擎服务,也使用了类似 SSTable 的结构。对于用 Docker 部署 Elasticsearch 集群的实践可以参考下之前写的 Elasticsearch 实践(一)用 Docker 搭建 Elasticsearch 集群Elasticsearch 实践(二)用 Docker 搭建 Elasticsearch 集群

    参考资料

    第03课:数据复制
    第04课:数据分区
    第05课:服务发现和服务通信
    第06课:分布式存储系统的事务
    第07课:分布式一致性
    第08课:分布式事务实践
    第09课:共识问题
    第10课:架构设计理念

    阅读全文: http://gitbook.cn/gitchat/column/5b444ae694c0f60b4ec4a68c

    展开全文
  • 本文转载自:什么是分布式微服务架构?三分钟彻底弄懂什么是分布式和微服务 一、微服务简介 1. 微服务的诞生 微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统,随着互联网的发展已经很难...

    本文转载自:什么是分布式微服务架构?三分钟彻底弄懂什么是分布式和微服务


    一、微服务简介

    1. 微服务的诞生

    微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统,随着互联网的发展已经很难满足市场对技术的需求,于是我们从单独架构发展到分布式架构,又从分布式架构发展到 SOA 架构,服务不断的被拆分和分解,粒度也越来越小,直到微服务架构的诞生。

    微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。

    每个服务运行在其独立的进程中,服务和服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。

    2. 微服务架构与SOA架构的区别

    微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部,去掉一个大一统的 ESB,服务间轻通信,是比 SOA 更彻底的拆分。

    微服务架构强调的重点是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用,这些小应用之间通过服务完成交互和集成。

    3. 微服务架构引发的问题

    随着整个业务数据被分散在各个子服务之后,也带来了两个最明显的问题。

    • 业务管理系统对数据完整性查询,比如分页查询、多条件查询等,数据被割裂后如何来整合?
    • 数据分析挖掘,这些需求可能需要分析全量的数据,并且在分析时不能影响到当前业务

    从技术方案来讲,我们一般有两种选择来处理这些问题,第一种是在线处理数据,第二种是离线处理数据。

    • 在线处理数据的方案:通过微服务提供的接口来获取数据,然后进行数据整合,不过这种方式有着明显的弊端,就是调用者需要编写大量的代码进行数据处理。其次在对各个微服务进行调取数据时会影响微服务的正常业务处理性能

    • 离线处理数据方案:将业务数据准实时的同步到另外一个数据库中,在同步的过程中进行数据整合处理,以满足业务方对数据的需求,数据同步过来后,再提供另外一个服务接口专业负责对外输出数据信息,这种方案有两个特点:①数据同步方案是关键,技术选型有很多,如何选择切合公司业务的技术方案;②离线数据处理对微服务正常业务处理没有影响。

    推荐使用第二种,利用 Spring Boot 和 MongoDB 可以轻松的解决这个问题,通过技术手段将分裂到 N 个微服务的数据同步到 MongoDB 集群中,在同步的过程中进行数据清洗,来满足公司的各项业务需求

    在微服务架构中,有 大难题,那就是服务故障的传播性服务的划分分布式事务

    二、CAP 理论

    Consistency :指数据的强一致性。如果写入某个数据成功,之后读取,读到的都是新 写入的数据:如果写入失败,之后读取的都不是写入失败的数据。

    Availability :指服务的可用性

    Partition-tolerance :指分区容错

    在分布式系统中 P是基本要求,而单体服务是 CA 系统, 微服务系统通常是 AP 系统,即同时满足了可用性和分区容错。

    这就有了 个难题:在分布式系统中如何保证数据的一致性?这就是大家经常讨论的分布式事务

    三、分布式事务

    在微服务架构中,分布式事务 般的解决办法就是两阶段提交或者 三阶段提交,不管使用哪都存在事务失败,导致数据不 致的情况,关键时刻还得人工去恢复数据。

    • 第一阶段:发起一个分布式事务,交给事务协调器TC处理,TC向多有的参与事务的节点发送处理事务操作的准备操作。所有的参与节点执行准备操作,将Undo和Redo 信息写进日志,并向事务管理器返回准备操作是否成功
    • 第二阶段:事务管理器收集所有节点的准备操作是否成功,如果都成功,则通知所有的节点执行提交操作;如果有 个失败,则执行回滚操作

    两阶段提交,将事务分成两部分能够大大提高分布式事务成功的概率。如果在第 阶段都成功了,而执行第 阶段的某 个节点失败,仍然导致数据的不准确,这时一般需要人工去处 理,这就是当初在第一步记录日志的原因。另外,如果分布式事务涉及的节点很多,某 个节 点的网络出现异常会导致整个事务处于阻塞状态,大大降低数据库的性能。所以一般情况下, 尽量少用分布式事务。

    四、服务划分

    横向拆分:按照不同的业务域进行拆分,例如订单、营销、风控、积分资源等。形成独立的业务领域微服务集群。

    纵向拆分:把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务,下沉到底层,形成相对独立的原子服务层。这样一纵一横,就可以实现业务的服务化拆分。

    要做好微服务的分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求

    总之,微服务的设计一定要渐进式的,总的原则是服务内部高内聚,服务之间低耦合。

    微服务特点

    • 按照业务划分服务,单个服务代码量小,业务单一,易于维护
    • 每个微服务都有自己独立的基础组件,例如数据库、缓存等且运行在独立的进程中
    • 微服务之间的通信是通过HTTP协议或者消息组件,且具有容错能力
    • 微服务有一套服务治理的解决方案,服务之间不耦合,可以随时加入和剔除
    • 单个微服务能够集群化部署,并且有负责 均衡的能力
    • 整个微服务系统应该有完整的安全机制,包括用户验证,权限验证,资源保护
    • 整个微服务系统有链路追踪的能力
    • 有一套完整的实时日志系统

    1. 给数据库带来的挑战

    随着服务拆分后,我们遇到最大的问题就是后台管理的联合查询,每个微服务都有自己独立的数据库,那么后台该怎么处理?

    这里一般有如下几种方式:

    1. 严格按照微服务的划分来做,微服务相互独立,各微服务数据库也独立,后台需要展示数据时,调用各微服务的接口来获取对应的数据,再进行数据处理后展示出来,这是标准的用法,也是最麻烦的用法。
    2. 将业务高度相关的表放到一个库中,将业务关系不是很紧密的表严格按照微服务模式来拆分,这样既可以使用微服务,也避免了数据库分散导致后台系统统计功能难以实现,是一个折中的方案。
    3. 数据库严格按照微服务的要求来切分,以满足业务高并发,实时或者准实时将各微服务数据库数据同步到NoSQL数据库中,在同步的过程中进行数据清洗,用来满足后台业务系统的使用,推荐使用MongoDB、HBase等。

    三种方案在不同的公司我都使用过,第一种方案适合业务较为简单的小公司;第二种方案,适合在原有系统之上,慢慢演化为微服务架构的公司;第三种适合大型高并发的互联网公司。

    五、熔断器

    为了解决分布式系统的雪崩效应,分布式系统引进了熔断器机制

    当一个服务的处理用户请求的失败次数在一定时间内小于设定的阀值时,熔断器出于关闭状态,服务正常。

    当服务处理用户请求失败次数在一定时间内大于设定的阀值时,说明服务出现故障,打开熔断器,这是所有的请求会快速失败,不执行业务逻辑

    当处于打开状态的熔断器时,一段时间后出于半打开状态,并执行一定数量的请求,剩余的请求会执行快速失败,若执行请求失败了,则继续打开熔断器,若成功了,则将熔断器关闭

    熔断器不仅能防止系统的“雪崩”效应,还具有以下作用

    • 将资源进行隔离
    • 服务降级的功能
    • 自我修复能力

    六、服务网关

    在微服务系统中,API 接口资源通常是有服务网关(也称API网关)统一暴露,内部服务不直接对外提供API资源的暴露。好处在于隐藏内部服务,保护系统安全

    网关层通常以集群的形式存在。并在服务网关层前通常会加上Nginx 用来负载均衡

    网关意义:

    • 网关将所有服务的API接口资源统一聚合,对外统一暴露
    • 网关可以做一些用户身份认证,权限认证,防止非法请求操作API 接口,对内部服务起到保护作用
    • 网关可以实现监控功能,实时日志输出、对请求进行记录
    • 网关可以用来做流量监控,在高流量的情况下,对服务进行降级
    • API 接口从内部服务分离出来,方便做测试

    当然,网关实现这些功能,需要做高可用,否则网关很可能成功架构的瓶颈,最常用的网关组件Zuul、Nginx

    七、服务配置统一管理

    在微服务架构中,需要有统一管理配置文件的组件,例如:SpringCloud Config组件、阿里的Diamond、百度的Disconf、携程的Apollo等

    八、服务链路追踪

    在微服务架构中,必须实现分布式链路追踪,去跟进一个请求到底有哪些服务参与、参与顺序,是每个请求链路清晰可见,便于问题快速定位

    常用链路追踪组件有Google的Dapper、Twitter 的Zipkin,以及阿里Eagleeye(鹰眼)

    九、微服务框架

    市面常用微服务框架有:Spring Cloud 、Dubbo 、kubernetes

    • 从功能模块上考虑,Dubbo缺少很多功能模块,例如网关、链路追踪等
    • 从学习成本上考虑,Dubbo 版本趋于稳定,稳定完善、可以即学即用,难度简单,Spring cloud 基于Spring Boot,需要先掌握Spring Boot ,例外Spring cloud 大多为英文文档,要求学习者有一定的英文阅读能力
    • 从开发风格考虑,Dubbo倾向于xml的配置方式,Spring cloud 基于Spring Boot ,采用基于注解和JavaBean配置方式的敏捷开发
    • 从开发速度上考虑,Spring cloud 具有更高的开发和部署速度
    • 从通信方式上考虑,Spring cloud 基于HTTP Restful 风格,服务于服务之间完全无关、无耦合。Dubbo 基于远程调用,对接口、平台和语言有强依赖性,如果需要实现跨平台,需要有额外的中间件。

    所以Dubbo专注于服务治理;Spring Cloud关注于微服务架构生态。

    十、SpringCloud常用组件

    • Eureka:服务注册和发现组件
    • Hystrix:熔断组件
    • Ribbon:负载均衡组件
    • Zuul:路由网关

    以上4个组件来自于Netflix 公司,统称为Spring Cloud Netflix

    • Spring Cloud Config:配置文件统一管理
    • Spring Cloud Security:Spring Security组件封装,提供用户验证和权限验证,一般与Spring Security OAuth2 组一起使用,通过搭建授权服务,验证Token或者JWT这种形式对整个微服务系统进行安全验证
    • Spring Cloud Sleuth:分布式链路追踪组件,他分封装了Dapper、Zipkin、Kibana 的组件
    • Spring Cloud Stream:Spring Cloud框架的数据流操作包,可以封装RabbitMq,ActiveMq,Kafka,Redis等消息组件,利用Spring Cloud Stream可以实现消息的接收和发送

    一个简单的Spring Cloud 构建的微服务系统,通常由服务注册中心Eureka、网关Zuul、配置中心Config和授权服务Auth构成

    Spring Cloud Netflix功能:

    • 服务发现:可以注册Eureka实例,并且客户端可以使用Spring托管的Bean发现实例
    • 服务发现:可以使用声明性Java配置创建嵌入式Eureka服务器
    • 断路器:Hystrix客户端可以使用简单的注释驱动的方法装饰器构建
    • 断路器:具有声明性Java配置的嵌入式Hystrix仪表板
    • 声明式REST客户端:Feign创建一个用JAX-RS或Spring MVC注释修饰的接口的动态实现。
    • 客户端负载均衡器:功能区
    • 外部配置:从Spring Environment到Archaius的桥梁(使用Spring Boot约定启用Netflix组件的本机配置)
    • 路由器和过滤器:Zuul过滤器的自动重新注册,以及用于反向代理创建的简单配置约定

    本文转载自:什么是分布式微服务架构?三分钟彻底弄懂什么是分布式和微服务

    展开全文
  • 一、分布式微服务架构设计原理

    千次阅读 2020-02-29 09:04:08
    文章目录一、 从传统单体架构服务架构JEE架构SSH架构:struts+spring+hibernate服务架构(SOA)1. web service:soap协议(在HTTP/HTTPS通道上传输XML数据)2. ESB:企业服务总线的简称,用于设计和实现网络化...

    一、 从传统单体架构到服务化架构

    JEE架构

    JEE将企业级软件架构分为三个层级:web层、业务逻辑层和数据存取层,每个层次的职责分别如下
        Web层:负责与用户交互或者对外提供接口
        业务逻辑层:为了实现业务逻辑而设计的流程处理和计算处理模块
        数据存取层:将业务逻辑层处理的结果持久化以待后续查询,并维护领域模型中对象的生命周期。

    SSH架构:struts+spring+hibernate

    服务化架构(SOA)

    1. web service:soap协议(在HTTP/HTTPS通道上传输XML数据)

    2. ESB:企业服务总线的简称,用于设计和实现网络化服务交互和通信的软件模型

    • ESB的核心在于企业服务总线的功能和职责:
          监控和控制服务之间的消息路由
          控制可插拔的服务化的功能和版本
          解析服务之间交互和通信的内容和格式
          通过组合服务、资源和消息处理器来统一编排业务需要的信息处理流程
          使用冗余来提供服务的备份能力

    二、 从服务化到微服务

    微服务架构的产生

    • 微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务,子服务之间通过良好的接口定义通信机制,通常使用RESTful风格的API形式来通信,因为RESTful风格的API通常是在HTTP或者HTTPS通道上传输JSON格式的数据来实现的,HTTP协议有跨语言、跨异构系统的有点,当然,也可以通过底层的二进制协议、消息队列协议等进行交互。这些服务不需要中心化的统一管理,每个服务的功能可自治,并且可以由不同的语言,系统和平台实现。

    • 微服务架构致力于松耦合和高内聚的效果,与SOA和ESB相比,不在强调服务总线和通信机制的多样性,常常通过RESTful风格的API和轻量级的消息通信协议来完成。

    • 微服务架构可以追溯到UNIX操作系统的管道命令

    • 微服务架构并不是为了拆分而拆分,真正的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题。而且拆分的为服务系统中专业的人做专业的时,人员和项目的职责单一、低耦合、高内聚,所以产生问题的概率就会降到最小。

    微服务架构与传统单体架构的对比

    微服务架构:

    -微服务把每一个职责单一的功能放在一个独立的服务中

    • 每个服务运行在一个单独的进程中
    • 每个服务有多个实例在运行,每个实例可以运行在容器化平台内,达到平滑收缩的效果
    • 每个服务有自己的数据存储,实际上,每个服务应该有自己独享的数据库、缓存、消息队列等资源
    • 每个服务应该有自己的运营平台,以及独享的运营人员,这包括技术运维和业务运营人员;每个服务都高度自治,内部的变化对外透明。
    • 每个服务都可根据性能需求独立地进行水平伸缩

    传统单体架构:

    • 传统单体架构将所有模块化组件混合后运行在同一个服务JVM进程中;可对包含多个模块化组件的整体JVM进程进行水平扩展,而无法对某个模块化组件进行水平扩展,某个模块化组件发生变化时,需要所有的模块化组件进行编译、打包和上线,久而久之,模块间的依赖将会不清晰,互相耦合、互相依赖成为家常便饭

    微服务架构与SOA服务化的对比

    目的不同

    • SOA服务化涉及的范围更广一些,强调不同的异构服务之间的协作和契约,并强调有效集成、业务流程编排、历史应用集成等,典型代表为WebService和ESB
    • 微服务使用一系列的微小服务来实现整体的业务流程,目的是有效地拆分应用,实现敏捷开发和部署,在每个微小服务的团队里,减少了跨团队的沟通,让专业的人做专业的事,缩小变更和迭代影响的范围,并达到单一的微服务更容易水平扩展的目的。

    部署方式不同

    SOA服务化同城将多个业务服务通过组件化模块方式打包在一个War包里,然后统一部署在一个应用服务器上
    微服务将完整的应用拆分成多个细小的服务,通常使用敏捷扩容、缩容的Docker技术来实现自动化的容器管理,每个微服务运行在单一的进程内,微服务中的部署互相独立,互不影响。
    

    服务粒度不同

    • SOA对粒度没有要求,在实践中服务通常是粗粒度的,强调接口契约的规范化,内部实现可以更粗粒度
    • 微服务倡导将服务拆分成更细的粒度,通过多个服务组合来实现业务流程的处理,拆分到职责单一,甚至小到不能再进行拆分。

    三、微服务架构的核心要点和实现原理

    微服务架构中职能团队的划分

    • 微服务架构按照业务的功能进行划分,每个单一的业务功能叫做一个服务,每个服务对应一个独立的职能团队,团队里包含用户交互UI设计师,后台服务开发人员、DBA、运营和运维人员。
    • 在微服务架构中,提倡运维人员也是服务项目团队的一员,倡导谁开发、谁维护,实施终生维护制度。
    • 在业务服务的内部实现需要升级或者变更时,团队内的各角色成员进行沟通即可,而不需要进行跨团队沟通,这大大提高了沟通效率,只有服务之间的接口需要变更时才需要跨部门沟通,可以通过一定的设计模式和规范来解决。

    微服务的去中心化治理

    微服务倡导去中心的治理,不推荐每个微服务都是用相同的标准和技术来开发和使用服务。在微服务架构下可以使用C++开发一个服务,来对接Java开发的另外一个服务,对于异构系统之间的交互标准,通常可以使用工具来补偿。开发者可以开发共用的工具,并分享給异构系统的开发者使用,来解决异构系统不一致的问题。
    微服务架构倡导去中心化的服务管理和治理,尽量不设置中心化的管理服务,最差也需要在中心化的管理服务宕机时有替代方案和设计。

    微服务的交互模式

    读者容错模式:指微服务化中服务提供者和消费者之间如何对接口的改变进行容错
    消费者驱动契约模式:用来定义服务化中服务之间交互接口改变的最佳规则。
    服务契约分为:提供者契约、消费者契约及消费者驱动的契约
    去数据共享模式:
    在设计微服务架构时,一定不要共享缓存和数据库等资源,也不要使用总线模式,服务之间的通信和交互只能依赖定义良好的接口,通常使用RESTful样式的API或者透明的RPC调用框架

    微服务的分解和组合模式

    • 服务代理模式
    • 服务聚合模式
    • 服务串联模式
    • 服务分支模式
    • 服务异步消息模式
    • 服务共享数据模式:应用场景:单元化架构、遗留的整体服务

    微服务的容错模式

    • 舱壁隔离模式
      微服务容器分组、线程池隔离
    • 熔断模式
    • 限流模式:计数器、令牌筒、信号量
    • 失效转移模式

    微服务的粒度

    根据业务需要,能够满足上层服务对底层服务自由编排并获得更多的业务功能即可,并需要适合团队的建设和布局。

    四、Java平台微服务架构的项目组织形式

    微服务项目的依赖关系

    一方库:本服务在jvm进程内依赖的jar包
    二方库:在服务外通过网络通信或者RPC调用的服务的jar包
    三方库:所依赖的其他公司或者组织提供的服务或者模块

    微服务项目的层级关系

    服务导出层
    接口层
    逻辑实现层
    

    微服务项目的持续发布

    代码管理、自动编译、发布QA、自动化测试、性能测试、准生产部署和测试、生产环境发布等。

    五、服务化管理和治理框架的技术选型

    • RPC:JDK RMI、Hessian及Burlap
    • 服务化:Dubbo、HSF、Thrift、AXIS、Mule ESB
    • 微服务:spring boot、Netflix、spring cloud Netflix
    展开全文
  • 2、SSH架构:Structs(UI交互层)、Spring(业务逻辑实现)、Hibernate(对象领域的模型与关系型数据库模式映射)StructsMVC模型:Spring:逻辑层实现核心容器,核心思想IOC和AOPa、IOC(控制反转):EJB实现:实现...
  • 分布式微服务架构.zip

    2021-09-06 18:03:51
    分布式微服务架构
  • 新版SpringCloud分布式微服务架构实战,PDF文档,一共10章,喜欢的童鞋可以下载,,,,,,,,
  • SpringCloud分布式微服务架构入门.技术选型,对比Dubbo到底怎么选的好。介绍CAP的基本概念,以及SpringCloud的实现方式
  • 1.3 分布式微服务架构 5 1.3.1 微服务概述 5 1.3.2 SOA与微服务 6 1.3.3 微服务架构的特点 6 1.3.4 微服务架构的缺点 7 1.3.5 微服务架构全景图 7 1.3.6 微服务类型 9 1.3.7 微服务拆分原则与步骤 9 第2章 ...

    开心一笑

    一次批小学语文卷,要求用"有……有……还有……"造句。一学生是这样写的:昨天去奶奶家,奶奶给我拿个鸡腿,我都吃完了问奶奶还有吗,奶奶答:“有,有,还有!”

    购买地址

    淘宝:https://s.taobao.com/search?q=%E5%88%86%E5%B8%83%E5%BC%8F%E5%BE%AE%E6%9C%8D%E5%8A%A1%EF%BC%9A%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E6%88%98&imgfile=&js=1&stats_click=search_radio_all%3A1&initiative_id=staobaoz_20191031&ie=utf8

    书籍目录

    资料目录:
    第1章 从架构演进启程 1
    1.1 水平分层架构 1
    1.1.1 概述 1
    1.1.2 MVC架构/水平分层架构 2
    1.2 SOA服务化架构 4
    1.2.1 SOA概述 5
    1.2.2 SOA的特征 5
    1.2.3 SOA面临的问题 5
    1.3 分布式微服务架构 5
    1.3.1 微服务概述 5
    1.3.2 SOA与微服务 6
    1.3.3 微服务架构的特点 6
    1.3.4 微服务架构的缺点 7
    1.3.5 微服务架构全景图 7
    1.3.6 微服务类型 9
    1.3.7 微服务拆分原则与步骤 9
    第2章 微服务开发框架 11
    2.1 环境准备 11
    2.1.1 安装JDK 11
    2.1.2 安装 Intellij IDEA 14
    2.1.3 安装 Apache Maven 14
    2.2 一分钟快速搭建Spring Boot项目 15
    2.2.1 使用Spring Initializr新建项目 15
    2.2.2 测试 18
    2.3 Spring Boot简单介绍 18
    2.3.1 Spring Boot核心功能及特性 19
    2.3.2 Spring Boot的缺点 20
    2.4 Spring Boot目录介绍 20
    2.4.1 Spring Boot工程目录 20
    2.4.2 Spring Boot入口类 21
    2.4.3 Spring Boot测试类 22
    2.4.4 pom文件 23
    2.5 Spring Boot生产级特性 24
    2.5.1 应用监控 24
    2.5.2 健康检查 28
    2.5.3 跨域访问 29
    2.5.4 外部配置 30
    第3章 分布式RPC框架 31
    3.1 RPC框架概述 31
    3.1.1 定义 31
    3.1.2 RPC核心组件 31
    3.1.3 RPC调用过程 32
    3.1.4 RPC框架调用分类 33
    3.1.5 RPC框架性能 35
    3.1.6 RPC框架与分布式服务框架 35
    3.2 RPC框架 36
    3.2.1 RMI远程方法调用 36
    3.2.2 Thrift 37
    3.2.3 Hessian 38
    3.2.4 Avro-RPC 38
    3.2.5 gRPC 38
    3.2.6 其他RPC框架 39
    第4章 序列化与反序列化 40
    4.1 序列化与反序列化 40
    4.1.1 序列化/反序列化概念 40
    4.1.2 序列化/反序列化特性 41
    4.2 常用序列化框架 41
    4.2.1 Java默认序列化 41
    4.2.2 XML序列化框架 46
    4.2.3 JSON序列化框架 48
    4.2.4 ProtoBuf序列化框架 50
    第5章 微服务底层通信与协议 54
    5.1 Java网络通信 54
    5.1.1 传统BIO编程 54
    5.1.2 伪异步I/O编程 60
    5.1.3 NIO编程 62
    5.2 Netty框架 78
    5.2.1 Netty概述 78
    5.2.2 第一个Netty应用程序 78
    5.2.3 Netty架构设计 84
    5.3 分布式服务框架协议 89
    5.3.1 主流公有协议 89
    5.3.2 私有协议设计 90
    第6章 服务路由与负载均衡 94
    6.1 服务路由概述 94
    6.1.1 定义 94
    6.1.2 服务信息存放方式 94
    6.2 服务路由概述 95
    6.2.1 定义 95
    6.2.2 负载均衡的实现 95
    6.2.3 负载均衡算法 98
    第7章 微服务注册中心 103
    7.1 微服务注册中心 103
    7.1.1 注册中心几个概念 103
    7.1.2 注册中心 104
    7.2 ZooKeeper实现服务注册中心 104
    7.2.1 ZooKeeper概述 104
    7.2.2 ZooKeeper的原理 105
    7.2.3 ZooKeeper的安装 106
    7.2.4 ZooKeeper搭建集群环境 109
    7.2.5 ZooKeeper集群总体架构 110
    7.2.6 命令行客户端zkCli.sh 112
    7.2.7 ZkClient连接ZooKeeper 116
    7.2.8 ZooKeeper实现服务注册与发现 120
    第8章 微服务框架服务调用与容错 122
    8.1 服务调用概述 122
    8.2 服务调用方式 123
    8.2.1 同步服务调用 123
    8.2.2 异步服务调用 125
    8.2.3 并行服务调用 130
    8.2.4 泛化调用 132

    第9章 分布式微服务封装与部署 133
    9.1 微服务封装技术 133
    9.1.1 Docker概述 133
    9.1.2 Docker的基本概念 135
    9.1.3 Docker架构 135
    9.1.4 Docker的安装 137
    9.1.5 Docker的常用命令 138
    9.1.6 制作镜像 142
    9.1.7 使用Dockerfile构建镜像 144
    9.1.8 Spring Boot集成Docker 147
    9.2 微服务部署概述 150
    9.2.1 蓝绿部署 150
    9.2.2 滚动发布 152
    9.2.3 灰度发布/金丝雀部署 154
    第10章 分布式服务限流 155
    10.1 服务限流概述 155
    10.1.1 限流定义 155
    10.1.2 限流算法 155
    10.2 限流设计 157
    10.2.1 限流设计 157
    10.2.2 分级限流 158
    第11章 服务降级、熔断、调度 159
    11.1 服务降级概述 159
    11.2 服务降级方式 159
    11.2.1 服务降级开关 159
    11.2.2 自动降级 160
    11.2.3 读服务降级 161
    11.2.4 写服务降级 161
    11.3 服务容错策略 161
    11.3.1 失败转移(Failover) 162
    11.3.2 失败自动恢复(Failback) 162
    11.3.3 快速失败(Failfast) 162
    11.3.4 失败缓存(FailCache) 162
    11.4 Hystrix降级、熔断 162
    11.4.1 Hystrix简介 162
    11.4.2 Hystrix实现降级/熔断 164
    11.5 服务优先级设计 165
    11.5.1 服务实例数量调整 165
    11.5.2 加权优先级队列 166
    11.5.3 线程调度器 167
    第12章 服务版本与服务发布 168
    12.1 概述 168
    12.2 服务版本概述 168
    12.2.1 概述 168
    12.2.2 Snapshot和Release 169
    12.3 服务发布 169
    12.3.1 概述 169
    12.3.2 服务发布方式 170
    第13章 分布式微服务日志中心 173
    13.1 分布式日志概述 173
    13.1.1 结构化日志/非结构化日志 173
    13.1.2 日志类型 175
    13.2 日志框架 175
    13.2.1 JDK Logger 175
    13.2.2 Apache Commons Logging 177
    13.2.3 Log4j/Log4j 2 177
    13.2.4 Spring Boot集成Log4j 179
    13.2.5 Docker日志框架 181
    13.2.6 Linux系统Syslog 183
    13.3 搭建日志中心 183
    13.3.1 ELK概述 183
    13.3.2 Elasticsearch日志存储 184
    13.3.3 Logstash日志收集 189
    13.3.4 Fluentd日志收集 191
    13.3.5 Kibana日志查询 193
    13.3.6 ELK架构与Docker整合 194
    13.3.7 ELK架构原理 195
    第14章 分布式微服务监控 197
    14.1 分布式服务架构监控 197
    14.1.1 监控的价值 197
    14.1.2 监控的完整体系 197
    14.1.3 微服务监控类型 198
    14.1.4 Spring Boot应用监控 198
    14.1.5 Spring Boot Admin监控系统 201
    14.2 搭建系统监控中心 206
    14.2.1 概述 206
    14.2.2 时序数据收集系统:cAdvisor 206
    14.2.3 时序数据存储系统:InfluxDB 209
    14.2.4 时序数据分析系统:Grafana 212
    14.2.5 集成InfluxDB + cAdvisor + Grafana 214
    第15章 分布式微服务配置中心 218
    15.1 配置中心概述 218
    15.1.1 概述 218
    15.1.2 配置中心解决问题 218
    15.1.3 全局配置 219
    15.1.4 配置中心 221
    15.2 Spring Cloud Config 223
    15.2.1 概述 223
    15.2.2 Spring Cloud Config快速入门 224
    第16章 分布式微服务存储与解耦 232
    16.1 分布式数据库架构 232
    16.1.1 分库 232
    16.1.2 分表 233
    16.1.3 水平切分的方式 233
    16.1.4 垂直切分的方式 235
    16.1.5 分组 235
    16.1.6 Mycat分库分表实战 236
    16.1.7 Spring+MyBatis+Mycat快速体验 240
    16.2 分布式事务 249
    16.2.1 数据库事务 249
    16.2.2 分布式事务 249
    16.2.3 CAP定理 250
    16.2.4 BASE理论 251
    16.2.5 两阶段提交(2PC) 252
    16.2.6 补偿事务(TCC) 252
    16.2.7 后置提交 254
    16.2.8 本地消息表(异步确保) 255
    16.3 分布式缓存架构 256
    16.3.1 Memcache与Redis 256
    16.3.2 进程内缓存 257
    16.3.3 Redis单节点安装 259
    16.3.4 Redis持久化策略 260
    16.3.5 Redis主从复制模式 263
    16.3.6 Redis哨兵模式 266
    16.3.7 Redis哨兵模式安装部署 271
    16.3.8 Redis集群模式 277
    16.3.9 Redis集群环境搭建 280
    16.3.10 Redis缓存穿透和雪崩 288
    16.4 微服务解耦 294
    16.4.1 服务解耦概述 294
    16.4.2 Kafka介绍 295
    16.4.3 Kafka安装 299
    16.4.4 Kafka搭建集群环境 300
    16.4.5 Kafka Manager的安装 301
    16.4.6 Kafka常用命令 301
    16.4.7 Spring Boot集成Kafka 311
    16.5 分布式服务Session 315
    16.5.1 Session与Cookie 315
    16.5.2 Session一致性问题 315
    16.5.3 Session同步 316
    第17章 分布式微服务测试 318
    17.1 分布式微服务测试 318
    17.1.1 概述 318
    17.1.2 微服务测试 319
    17.2 Spring Boot单元测试 321
    17.3 Mockito/PowerMockito测试框架 323
    17.3.1 Mockito概述 323
    17.3.2 Mockito简单实例 324
    17.3.3 PowerMock概述 327
    17.3.4 PowerMockito简单实例 327
    17.4 H2内存型数据库 330
    17.4.1 H2概述 330
    17.4.2 Spring Boot集成H2 330
    17.5 REST API测试 333
    17.5.1 Postman概述 333
    17.5.2 Postman简单使用 333
    17.6 性能测试 336
    17.6.1 ab概述 336
    17.6.2 ab测试 336
    17.6.3 其他性能测试工具 338
    第18章 分布式微服务架构经典案例 341
    18.1 微服务架构案例 341
    18.1.1 概述 341
    18.1.2 微服务架构平台选择 342
    18.1.3 微服务接口类型 342
    18.1.4 微服务类型 343
    18.2 分布式服务框架Dubbo 344
    18.2.1 Dubbo概述 344
    18.2.2 Dubbo原理 344
    18.3 Spring Boot + Spring Cloud解决方案 345
    18.3.1 Spring Boot概述 345
    18.3.2 Spring Cloud概述 345
    18.3.3 微服务、Spring Boot、Spring Cloud的关系 347
    18.3.4 Spring Cloud与Dubbo的优劣 348
    18.4 Spring Boot + Kubernetes + Docker解决方案 348
    18.4.1 Docker概述 348
    18.4.2 Kubernetes概述 349
    18.4.3 Kubernetes的基本概念 349
    18.4.4 Kubernetes的使用 352
    18.4.5 Kubernetes的架构 356
    18.4.6 Kubernetes集群监控 360
    18.4.7 Kubernetes集群日志管理 360
    18.4.8 Kubernetes解决方案 360
    参考文献 362

    读书感悟

    来着 纳西姆·尼古拉斯·塔勒布《反脆弱》

    • 唤醒天才的是困难。
    • 反脆弱的策略就是记住:意外总会发生。
    • 让人上瘾的东西里,害处最大的三种是海洛因、碳水化合物和月薪。
    • 人们了解的很多东西其实都不值得去了解。
    • 如果有人跟你说“我很忙”,那他要么是在宣称自己的无能(以及对自己的生活的缺乏控制),要么是在试图摆脱你。
    • 不管在哪个领域,业余爱好者往往都是最优秀的。
    • 这个世界上真正的贵人从来不是别人,而是我们自己。人只要记住一个原则,不管是做什么事,不管是在什么环境中,尽可能做到利人利己,你会发现事情一定会越来越好,你的贵人也会越来越多。
    • 与一个无知的人保持距离相当于与一个聪明人为伍。

    经典故事

    赵国有一户人家被老鼠害苦了,就到中山国去借猫,中山人给了他一只。
    这只猫很会捉老鼠,但是也喜欢捉鸡吃。
    一个月之后,他家的老鼠被捉干净了,而鸡也被吃光了。
    他的儿子认为这只猫是个祸害,对父亲说:“为什么不把它除掉呢?”
    父亲说:“我们的祸患在于家里有老鼠,不在于没有鸡。老鼠偷吃粮食,咬烂衣物,钻穿墙壁,啃坏家具,这样下去我们就要挨饿受冻,这比没有鸡更糟!没有鸡,我们只不过不吃鸡肉罢了,离挨饿受冻还远呢!为什么要把猫除掉呢?”
    点评:【古人云:“两害相权取其轻,两利相权取其重。”意思是两种利益同时放面前,当然是选择利益较大的那种;两种损害放面前,当然是选择伤害较轻的那种。简单地说,就是权衡利弊,首选利重害轻。】

    大神文章

    其它

    如果有带给你一丝丝小快乐,就让快乐继续传递下去,欢迎鼓励,点赞、顶、欢迎留下宝贵的意见、多谢支持!

    展开全文
  • 1、分布式微服务架构设计原理

    千次阅读 2020-04-04 11:41:59
    1、技术架构演进 (单体架构服务架构、微服务化架构) 单体架构:JEE、SSH 服务架构:WebService、ESB服务总线 微服务化架构:SpringBoot 2、微服务架构核心要点和实现原理 3、微服务框架技术选型
  • linux部署分布式微服务架构.docxlinux部署分布式微服务架构.docxlinux部署分布式微服务架构.docx
  • 分布式微服务架构体系学习分享。 作为一个架构师或者想在技术架构领域深耕的开发人员,在做技术选型及方案时,更需要对这些技术的实现思路、算法以及优点和限制进行了解。 把微服务架构结合 Docker 的一些技术选型...
  • Spring Cloud分布式微服务架构
  • 分布式微服务架构

    2020-05-24 15:11:05
    从单体/垂直架构转移到分布式/微服务架构是自然而然的选择. 01分布式理论 分布式理论是分布式系统的基础, 在任何情况下分布式系统都要满足网络分区容错性, 因此分布式系统都是在可用性和一致性方面做平衡. 02CAP...
  • 近些年分布式框架很是火热,目前国内使用最多的框架是阿里的Dubbo体系架构,最近也有很多公司转型到Spring Cloud的怀抱,还有一部分选择自建分布式微服务架构。 本片博文主要讲述开发者使用自建的方式搭建微服务...
  • 从零搭建基于 Docker 容器技术的微服务分布式企业集群,深度的 DDD 思想践行者。CSDN 博客专家。微服务架构的演变微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建,或者当现有架构已到...
  • 使用spring cloud代建完整的分布式微服务架构,包括spring security oauth2权限控制,docker,config动态修改配置文件,eureka服务发现,zuul路由,实现服务服务之间的调用
  • 分布式微服务架构解决方案编写的实战项目 目前暂时只完成项目基本架构。 分布式链路追踪,分布式服务监控,分布式协调系统,分布式配置中心,Spring Cloud 全家桶解决方案 来做到高可用,高性能,高并发 单点登录,...
  • Zookeeper分布式微服务架构解决方案编写的实战项目 众所周知微服务要解决的最大问题就是网络不可靠的问题,而服务之间的通行可以用Dubbo 这款轻量级的开源 Java RPC 分布式服务框架:Dubbo提供了三大核心能力:面向...
  • agile-parent Agile 分布式微服务架构综合脚手架
  • Spring Boot 一直以来,备受大家关注,也被...并且结合 k8s 来实现微服务结构设计,服务注册与发现以及配置管理等相关组件统统不需要,只要有 k8s 即可,是不是很神奇呢? 本场 Chat 旨在让大家学会使用 Spring Bo...
  • 今天正式给大家介绍了Spring Cloud - 企业分布式微服务架构构建,我这边结合了当前大部分企业的通用需求,包括技术的选型比较严格、苛刻,不仅要用业界最流行的技术,还要和国际接轨,在未来的5~10年内不能out。...
  • 六、分布式架构常见问题 6.1 服务之间的异步通讯 6.2 服务之间通讯地址的维护. 6.3 服务降级 6.4 海量数据 七、微服务架构 7.1 微服务架构 7.2 模块过多,运维成本增加 7.3 分布式架构下的其他问题 7.3.1 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 45,699
精华内容 18,279
关键字:

分布式微服务架构