分布式架构

ZooKeeper 概述 Zookeeper 是一个分布式协调服务的开源框架。 主要用来解决分布式集群中 应用系统的一致性问题，例如怎样避免同时操作同一数据造成脏读的问题。 ZooKeeper 本质上是一个分布式的小文件存储系统。 提供基于类似于文件系 统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维 护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达 到基于数据的集群管理。 诸如： 统一命名服务(dubbo)、分布式配置管理(solr的配置集中管理)、分布式消息队列（sub/pub）、分布式锁、分布式协调等功能。 2.1、zookeeper的架构图 Leader: Zookeeper 集群工作的核心 事务请求（写操作） 的唯一调度和处理者，保证集群事务处理的顺序性； 集群内部各个服务器的调度者。 对于 create， setData， delete 等有写操作的请求，则需要统一转发给leader 处理， leader 需要决定编号、执行操作，这个过程称为一个事务。 Follower: 处理客户端非事务（读操作） 请求， 转发事务请求给 Leader； 参与集群 Leader 选举投票 2n-1台可以做集群投票。 此外，针对访问量比较大的 zookeeper 集群， 还可新增观察者角色。 Observer: 观察者角色，观察

一个复杂的系统往往都是从一个小而简的系统发展衍化而来，为了满足日益增长的业务需求，不断的增加系统的复杂度，从单体架构逐步发展为分布式架构，而分布式系统架构的设计主要关注：高性能，高可用，高拓展 分布式事务 高可用是指系统无中断的执行功能的能了，代表了系统的可用程度，是进行系统设计时必须要遵守的准则之一。 而高可用的实现方案，无外乎就是冗余，就存储的高可用而言，问题不在于如何进行数据备份，而在于如何规避数据不一致对业务造成的影响 对于分布式系统而言，要保证分布式系统中的数据一致性就需要一种方案，可以保证数据在子系统中始终保持一致，避免业务出现问题，这种实现方案就叫做分布式事务，要么一起成功，要么一起失败，必须是一个整体性的事务 理论基础 ​ 在讲解具体方案之前，有必要了解一下分布式中数据设计需要遵循的理论基础，CAP理论和BACS理论，为后面的实践铺平道路 CAP理论 CAP：Consistency Acailability Partition tolerance 的简写 Consistency：一致性 对某个客户端来说，读操作能够返回最新的写操作结果 Acailability：可用性 非故障节点在合理的时间内返回合理的响应 Partition tolerance：分区容错性 当出现网络分区后，系统能够继续提供服务 你知道什么是网络分区吗 ~~

摘要: Jeesz主要定位于互联网企业架构，已内置企业信息化系统的基础功能和高效的代码生成工具，包括：系统权限组件、数据权限组件、数据字典组件、核心工具 组件、视图操作组件、工作流组件、代码生成等。采用分层设计、双重验证、提交数据安全编码、密码加密、访问验证、数据权限验证。 平台简介 Jeesz是一个分布式的框架，提供项目模块化、服务化、热插拔的思想，高度封装安全性的 Java EE快速开发平台。 Jeesz本身集成Dubbo服务管控、Zookeeper注册中心、 Redis 分布式缓存技术、FastDFS分布式文件系统、ActiveMQ异步消息中间件、Nginx负载均衡等分布式技术 使用Maven做项目管理，项目模块化，提高项目的易开发性、扩展性 以 spring Framework为核心容器，Spring MVC为模型视图控制器，MyBatis为数据访问层， Apache Shiro为权限授权层，Ehcahe对常用数据进行缓存，Activit为工作流引擎等。 前端集成Bootstrap4 metronic框架，UI响应式、扁平化布局，适应所有PC、Pad、Anroid、 iOS 移动设备等。 Jeesz主要定位于互联网企业 架构 ，已内置企业信息化系统的基础功能和高效的代码生成工具，包括：系统权限组件、数据权限组件、数据字典组件、核心工具 组件、视图操作组件、工作流组件

简介 消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。当下主流的消息中间件有RabbitMQ、Kafka、ActiveMQ、RocketMQ等。其能在不同平台之间进行通信，常用来屏蔽各种平台协议之间的特性，实现应用程序之间的协同。其优点在于能够在客户端和服务器之间进行同步和异步的连接，并且在任何时刻都可以将消息进行传送和转发。是分布式系统中非常重要的组件，主要用来解决应用耦合、异步通信、流量削峰等问题 消息中间件的作用 消息中间件几大主要作用如下: 解耦 降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 冗余(存储) 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕

SOA （面向服务编程）：Service Oriented Architecture面向服务的架构。也就是把工程拆分成 服务层 、 表现层 两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。 这样做的好处就是，系统之间的调用很方便，A系统要用到B系统，直接调用B系统的服务层就可以了。 集群 就是多台服务器跑的都是一套完整的代码，这就叫集群（水平拆分）； 分布式 就是多台服务器合起来跑的才是一套完整代码，这就叫分布式（垂直拆分） 分布式服务器之间如何解决通信的问题 -全部都是基于socket 分布式系统通信流程： 1、七层网络协议 tcp/udp协议（） 2、源主机找到目标主机 3、源主机和目标主机之间如何建立联系 　　tcp：面向连接（保存状态）的一种协议 　　　　优点：可靠 　　　　缺点：速度慢 　　udp：面向数据报（无连接，五状态） 　　　　优点：速度快 　　　　缺点：不可靠 　　3.1tcp协议 　　　　3.1.1 通过3此握手协议 　　　　　　　　客户端发起（syn）服务器响应（ack） 　　　　3.1.2 syn攻击 　　　　　　　　网络崩溃 　　　　3.1.3 通过4次回收协议、 　　　　　　　　客户端发起（fin）服务器响应（ack） 来源： https://www.cnblogs.com

上一篇文章讲述了如何利用Hystrix Dashboard去监控断路器的Hystrix command。当我们有很多个服务的时候，这就需要聚合所以服务的Hystrix Dashboard的数据了。这就需要用到Spring Cloud的另一个组件了，即Hystrix Turbine。 一、Hystrix Turbine简介 看单个的Hystrix Dashboard的数据并没有什么多大的价值，要想看这个系统的Hystrix Dashboard数据就需要用到Hystrix Turbine。了解springcloud架构可以加求求：三五三六二四七二五九,Hystrix Turbine将每个服务Hystrix Dashboard数据进行了整合。Hystrix Turbine的使用非常简单，只需要引入相应的依赖和加上注解和配置就可以了。 二、准备工作 本文使用的工程为上一篇文章的工程，在此基础上进行改造。因为我们需要多个服务的Dashboard，所以需要再建一个服务，取名为service-lucy，它的基本配置同service-hi，具体见源码,在这里就不详细说明。 三、创建service-turbine 引入相应的依赖： <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId

在第四篇文章断路器讲述了如何使用断路器，并简单的介绍了下Hystrix Dashboard组件，这篇文章更加详细的介绍Hystrix Dashboard。 一、Hystrix Dashboard简介 在微服务架构中为例保证程序的可用性，防止程序出错导致网络阻塞，出现了断路器模型。断路器的状况反应了一个程序的可用性和健壮性，它是一个重要指标。了解springcloud架构可以加求求：三五三六二四七二五九,Hystrix Dashboard是作为断路器状态的一个组件，提供了数据监控和友好的图形化界面。 二、准备工作 本文的的来源于第一篇文章的栗子，在它的基础上进行改造。 三、开始改造service-hi 在pom的工程文件引入相应的依赖： <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>

分布式篇 1 简述 分布式计算的基本理念是将工作划分为一个一个小任务，分发给多台设备处理，再汇总结果。在分布式计算中，网络中的机器必须要保持可用（延迟误差、意外宕机等等），需要一个持续监控架构 分布式多进程 2 multiprocessing 的子模块 managers 还支持把多进程分布在多台机器上， managers 模块已经封装好了网络通信的细节 实现方法 ：我们可以使用 managers 模块将 queue 队列通过网络暴露出去，让其它机器访问到这个队列，然后就可以通过它实现数据交换 示例： 服务器通过暴露queue到网络，放入数据到队列，让客户端取出数据处理，再放回结果 服务器代码 # task_master.py import random, time, queue from multiprocessing.managers import BaseManager # 发送任务的队列: task_queue = queue.Queue() # 接收结果的队列: result_queue = queue.Queue() # 从BaseManager继承的QueueManager: class QueueManager(BaseManager): pass # 把两个Queue都注册到网络上, callable参数关联了Queue对象: QueueManager

作者：大闲人柴毛毛 链接：https://www.zhihu.com/question/20004877/answer/282033178 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 画了一上午，麻烦点个赞～ 下面就正经解释下三种结构的区别吧～ 单机结构 我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式，往下接着看。 集群结构 集群模式在程序猿界有各种装逼解释，有的让你根本无法理解，其实就是一个很简单的玩意儿，且听我一一道来。 单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色

分布式RPC框架Apache Dubbo 1. 软件架构的演进过程 软件架构的发展经历了由单体架构、垂直架构、SOA架构到微服务架构的演进过程，下面我们分别了解一下这几个架构。 1.1 单体架构 架构说明： ​ 全部功能集中在一个项目内（All in one）。 架构优点： ​ 架构简单，前期开发成本低、开发周期短，适合小型项目。 架构缺点： ​ 全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。 ​ 技术栈受限，只能使用一种语言开发。 ​ 系统性能扩展只能通过扩展集群节点，成本高。 1.2 垂直架构 架构说明： ​ 按照业务进行切割，形成小的单体项目。 架构优点： ​ 技术栈可扩展（不同的系统可以用不同的编程语言编写）。 架构缺点： ​ 功能集中在一个项目中，不利于开发、扩展、维护。 ​ 系统扩张只能通过集群的方式。 ​ 项目之间功能冗余、数据冗余、耦合性强。 1.3 SOA架构 SOA全称为Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。 站在功能的角度，把业务逻辑抽象成可复用的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。 架构说明： ​