分布式部署

这书以分布式微服务系统为主线，讲解了微服务架构设计、分布式一致性、性能优化等内容，并介绍了与微服务系统紧密联系的日志系统、全局调用链、容器化等。 还是一样，每一章摘抄一些自己觉得有用的内容，归纳整理，然后加以理解。 第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基础设施，电信和其他。 分布式计算的演变 计算模型发展：单机 - >数据中心 -

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 理论并不适合数据库事务（因为更新一些错误的数据而导致的失败，无论使用什么样的高可用方案都是徒劳

XXL-JOB 源码和教程 实战 部署任务调度中心 jar部署 docker部署 配置执行器项目 遇见的问题 制作镜像 源码和教程 github源码 中文教程 实战 部署任务调度中心 jar部署 参考 中文教程 即可部署 docker部署 部署任务调度中心和Mysql(使用docker-compose) version : '3' services : mysql-xxljob : image : mysql container_name : mysql - xxljob ports : - 3306 : 3306 environment : TZ : Asia/Shanghai MYSQL_ROOT_PASSWORD : '123456' command : - - default - authentication - plugin=mysql_native_password - - character - set - server=utf8mb4 - - collation - server=utf8mb4_general_ci - - explicit_defaults_for_timestamp=true - - lower_case_table_names=1 - - max_allowed_packet=128M volumes : - mysql - data :

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

架构 环境 主机名 IP db1 192.168.31.205 db2 192.168.31.206 前期准备 开启防火墙，安装配置 mysql （db1,db2） firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="192.168.31.0/24" accept" firewall-cmd --reload mkdir /software # 把软件 mysql-5.7.20-linux-glibc2.12-x86_64.tar.gz 上传到 /software cd /usr/local/ tar zxf /software/mysql-5.7.20-linux-glibc2.12-x86_64.tar.gz mv mysql-5.7.20-linux-glibc2.12-x86_64 mysql # 初始化数据 mkdir /data/33{07..10}/data -p mysqld --initialize-insecure --user=mysql --datadir=/data/3307/data --basedir=/usr/local/mysql mysqld --initialize-insecure --user=mysql --datadir=/data