分布式架构

这书以分布式微服务系统为主线，讲解了微服务架构设计、分布式一致性、性能优化等内容，并介绍了与微服务系统紧密联系的日志系统、全局调用链、容器化等。 还是一样，每一章摘抄一些自己觉得有用的内容，归纳整理，然后加以理解。 第1章 分布式微服务架构设计原理 1. 由传统单体架构到服务化架构 （老生常谈，感觉所有谈到微服务的内容都是从这个角度开始叙述。） （1）J2EE是二八原则的典型应用场景：它将80%通用的与业务无关的逻辑和流程封装在应用服务器的模块化组件里，通过配置的模式提供给应用程序访问，应用程序实现20%的专用逻辑，并 通过配置的形式来访问应用服务器提供的模块化组件 。 （2）康威定律 设计系统的组织时，最终产生的设计等价于组织的沟通结构，通俗来说， 团队的交流机制应该与架构设计机制相对应 。 （3）Java AOP的实现方式有三种 1》对Java字节码进行 重新编译 ，将切面插入字节码的某些点和面上，可以使用 cglib库 实现 2》定制类加载器，在类加载时对字节码进行补充，在字节码中插入切面，增加了除业务逻辑外的功能，JVM自身提供的 Java Agent机制 就是在 加载类的字节码时 ，通过增加切面来实现AOP的。 3》JVM本身提供了 动态代理组件 ，可以通过它实现任意对象的代理模式， 在代理的过程中 可以插入切面的逻辑。可以使用Java提供的APIProxy

=======开篇吐槽：最近一段时间刚好碰上中秋国庆双节，而且工作任务繁重，基本很难保证有时间来写文章了======= 《可伸缩服务架构 框架与中间件》与《分布式服务架构 原理、设计与实战》是要配套捆绑着看，这营销手段，服。 这书主要介绍了在分布式系统中常规用到的一些框架组件，比如分布式ID、消息队列、缓存、RPC框架、ES等。书中大部分内容的作用更多的是整体介绍、知识点扩展、初步入门，书中贴的源代码其中很难让人认真一行一行去阅读学习。想要更深入的学习，需要在平时工作多积累丰富的项目经验，或者多看看开源项目，从而去总结和提取。 每一章介绍一个组件，摘抄一些自己觉得有用的内容，归纳整理，然后加以理解。（主要还是强迫自己形成总结成文的习惯，看的书很多，都总是很容易忘记，效果甚微） 第1章 如何设计一款永不重复的高性能分布式发号器 1. 为什么不直接采用UUID？ 虽然UUID能够保证唯一性，但无法满足业务系统需要的很多其他特性，比如时间粗略有序性、可反解和可制造性（说人话，就是分布式ID需要体现根据时间递增的特点，并且从ID串中能解析出一定的业务含义），同时UUID比较长，占空间大，性能较差。 2. 那基于数据库来实现呢？ 即通过调整自增字段或者数据库sequence的步长来确保跨数据库的ID的唯一性，但这种方案强依赖于数据库。 实现方案，可见我：重构 - 分布式ID设计方案 3.

1.1Hazelcast概述 Hazelcast是基于内存的数据网格开源项目，同时也是该公司的名称。Hazelcast提供弹性可扩展的分布式内存计算，Hazelcast被公认是提高应用程序性能和扩展性最好的方案。Hazelcast通过开放源码的方式提供以上服务。更重要的是，Hazelcast通过提供对开发者友好的Map、Queue、ExecutorService、Lock和JCache接口使分布式计算变得更加简单。例如，Map接口提供了内存中的键值存储，这在开发人员友好性和开发人员生产力方面提供了NoSQL的许多优点。 除了在内存中存储数据外，Hazelcast还提供了一组方便的api来访问集群中的cpu，以获得最大的处理速度。轻量化和简单易用是Hazelcast的设计目标。Hazelcast以Jar包的方式发布，因此除Java语言外Hazelcast没有任何依赖。Hazelcast可以轻松地内嵌已有的项目或应用中，并提供分布式数据结构和分布式计算工具。 Hazelcast 具有高可扩展性和高可用性（100%可用，从不失败）。分布式应用程序可以使用Hazelcast进行分布式缓存、同步、集群、处理、发布/订阅消息等。Hazelcast基于Java实现，并提供C/C++，.NET，REST，Python、Go和Node.js客户端。Hazelcast遵守内存缓存协议

我在区块链会议上就即将到来的公共“分布式云”系统进行了讨论，该系统将主流的公共云平台（如AWS，Azure，Google Cloud，Heroku等）与区块链和P2P网络相结合，比如以太坊，IPFS，EOS，TRON，NEM，NEO，Storj，Sia......为什么？因为分布式组织（DAO）和分布式计算的发展趋势很好，并且行业需要更强大的平台来构建和运行DApp（分布式应用程序）。 让我与大家分享一下我对未来分布式计算网络（也称为“分布式云平台”）的看法。 计算模型和软件系统一直在变化：从独立软件到客户端 - 服务器系统，再到基于云的基础架构和平台。现在，计算模型的下一个重大变革即将到来，它将影响许多行业：分布式，包括一种新型的分布式组织，执行分布式流程，使用分布式数据存储，分布式计算系统，运行和发展分布治理。区块链和其他分布式账本技术（DLT）以及即将推出的分布式数据库，存储系统和其他分布式计算组件将成为新的“分布式云”的核心，这将允许运行分布的IT基础架构和“软件组织” （DAO）在权力下放的治理下没有所有者，没有雇员。由于其透明性，安全性，可追溯性，降低成本和削减中间人的能力，这种区块链和分布运动为许多行业带来了创新和转型：财务，供应链，医疗保健，政府，预测，保险，流动性，投票， IT基础设施，电信和其他。 分布式计算的演变 计算模型发展：单机 - >数据中心 -

介绍 分布式服务框架是面向服务架构的基石，是解耦子系统的利刃。核心实现是RPC（远程过程调用），但又不仅限于RPC，因为一个系统的高效、稳定、可靠的运行还需要依赖于服务管理发现、服务部署运行监控跟踪等辅助系统的支撑。在一个大型系统中，服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要，这一点业内已经形成了共识。 目前主要使用的是Thriftpool以及Hedwig，除此之外，业内知名的几个服务框架还包括： Finagle -- Twitter开发并开源，专为JVM设计的一个可扩展的RPC系统，其核心的组件包括Future、Service以及Filter； Dubbo -- 阿里开发贡献的一个开源项目，是一个高性能分布式服务框架，它主要由三个核心部分组成：Remoting：提供远程调用的网络通信框架；集群：抽象出具有负载均衡、故障转移等集群能力；注册中心：一个服务注册框架，提供服务事件的发布订阅 Sofa-PBRPC -- 是一个轻量级的，基于Protobuf实现的一个RPC框架，由百度开发并开源，仅支持C++ Motan -- 新浪微博的RPC框架，序列化接口可扩展、具有集群方案，不开源 Poppy -- 腾讯基于Protocol Buffer的网络通信解决方案，除了RPC方式的编程接口之外，也具有集群方案，支持服务监控、调试

1. 分布式系统架构有哪些优势？ 1）增大系统容量 2）加强系统可用性 3）因为模块化，所以系统模块重用度更高 4）因为软件模块化被拆分，开发和发布速度可以并发而变得更快 5）系统扩展性更高 6）团队协作流程也会得到改善 2. 分布式系统架构有哪些劣势？ 1）架构设计变得复杂（尤其是其中的分布式事务） 2）部署单个服务会比较快，但如果一次部署多个服务，流程会变得复杂 3）系统的吞吐量会变大，但响应时间会边长。 4）运维复杂度会因为服务变多而变得复杂 5）架构复杂导致学习曲线变大 6）测试和查错的复杂度增大 7）技术多元化，这会带来维护和运维的复杂度 8）管理分布式系统中的服务和调度变得困难和复杂 来源： https://www.cnblogs.com/Jtianlin/p/12015390.html

什么是分布式锁 要介绍分布式锁，首先要提到与分布式锁相对应的是线程锁、进程锁。 1.线程锁 主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如Synchronized、Lock等。 2.进程锁 为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。 3.分布式锁 当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。 分布式锁的由来 在传统单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLcok或synchronized)进行互斥控制。 但是在分布式系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机并发控制锁策略失效，为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁的由来。 当多个进程不在同一个系统中，就需要用分布式锁控制多个进程对资源的访问。 分布式锁的特点 首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件： **1、互斥性：**任意时刻，只能有一个客户端获取锁，不能同时有两个客户端获取到锁。 **2、安全性：*

分布式架构设计 1.分布式架构的基本理论 2.SOA架构和微服务架构 3.领域驱动设计及业务驱动划分 ==================================== 一. 分布式架构的基本理论 1.CAP理论 一个经典的分布式系统理论。CAP 理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。 一致性（Consistency） 所有节点上的数据必须时刻保持一致 可用性（Availability） 可用性是指服务一直可用，而且是正常的响应时间 分区容错性（Partition tolerance） 系统应该持续提供服务，即时系统内部（某个节点分区）有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂；服务器发生网络延迟或死机，导致某些 server 与集群中的其他机器失去联系 总结： CAP 并不是一个普适性原理和指导思想，它仅适用于原子读写的 NoSql 场景中，并不适用于数据库系统。 2.BASE理论 从前面的分析中知道：在分布式（数据库分片或分库存在的多个实例上）系统下，CAP 理论并不适合数据库事务（因为更新一些错误的数据而导致的失败，无论使用什么样的高可用方案都是徒劳

平常一个B2B平台交互时，就需要服务器集群和分布式处理 一.服务器集群 如果一个Tomcat 可以处理500个并发请求（实际可以处理200~300的并发就不错了），那么10000个并发请求，就需要20台服务器做Tomcat集群,当tomcat集群中节点数据增加，服务器能力先增加后下降。所以集群中节点(服务器)数量不能太多，一般也就5个左右（节点如果多了就会使服务器性能呈抛物线形式发展），所以通过增加硬件来提高服务器性能是不可能了（就是因为Session复制问题），那么就需要软件来解决这个问题 ； 当然中间就需要一台负载均衡服务器（如：Nginx），然后将并发请求分布在两台服务器上或者更多服务器上，比如在登录tomcat1后，将登录信息进行session共享给tomcat2,这样才能保证好的体验度，就是说平常在硬件能解决问题的情况下，绝对不用软件，因为软件改起来比较麻烦，那就花钱呗，就是增加硬件服务器。 注： 关注点 Tomcat分享/广播登录信息（ Session复制导致集群节点太多，才会使性能呈抛物线 ）。 服务器集群 按照自己的理解就是一个工程运行在多个服务器上，自然做的事就是同一件事喽，达到共享信息，复制的功能。 二.分布式 1.个人理解： 需要按照功能点将系统进行拆分，拆分成独立的功能。单独为某一个节点添加服务器，需要系统之间配合才能完成整个业务逻辑，叫做分布式。

基础理论 SOA 到 MSA 的进化 SOA 面向服务架构 由于业务发展到一定程度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯。面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障时会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 MSA 微服务架构 微服务是真正意义上的独立服务，从服务入口到数据持久层，逻辑上都是独立隔离的，无需服务总线来接入，但同时也增加了整个分布式系统的搭建和管理难度，需要对服务进行编排和管理，所以伴随着微服务的兴起，微服务生态的整套技术栈也需要无缝接入，才能支撑起微服务的治理理念。 节点与网络 节点 传统的节点也就是一台单体的物理机，所有的服务都揉进去包括服务和数据库；随着虚拟化的发展，单台物理机往往可以分成多台虚拟机，实现资源利用的最大化，节点的概念也变成单台虚拟机上面服务；近几年容器技术逐渐成熟后，服务已经彻底容器化，也就是节点只是轻量级的容器服务。总体来说，节点就是能提供单位服务的逻辑计算资源的集合。 网络 分布式架构的根基就是网络，不管是局域网还是公网，没有网络就无法把计算机联合在一起工作，但是网络也带来了一系列的问题。网络消息的传播有先后，消息丢失和延迟是经常发生的事情，我们定义了三种网络工作模式： 同步网络 节点同步执行 消息延迟有限