我想知道dubbo性能压测的框架和软件，硬件的瓶颈分析？

来源：蜘蛛抓取(WebSpider) 时间：2022-07-23 13:49 标签： dubbo负载均衡策略如何配置

  • Stack 是线程安全的。
  • 内部使用数组保存数据，不够时翻倍。

每个节点最多有两个叶子节点。

  • 叶节点只能出现在最下层和次下层，并且最下面一层的结点都集中在该层最左边的若干位置的二叉树。

左右两个子树的高度差的绝对值不超过1，并且左右两个子树都是一棵平衡二叉树。

  • 添加阶段后，左旋或者右旋从而再次达到平衡。

MySQL是基于B+树聚集索引组织表

  • B+树的叶子节点链表结构相比于 B-树便于扫库，和范围检索。

    • B+ 树读性能好，但由于需要有序结构，当key比较分散时，磁盘寻道频繁，造成写性能。
    • LSM 是将一个大树拆分成N棵小树，先写到内存（无寻道问题，性能高），在内存中构建一颗有序小树（有序树），随着小树越来越大，内存的小树会flush到磁盘上。当读时，由于不知道数据在哪棵小树上，因此必须遍历（二分查找）所有的小树，但在每颗小树内部数据是有序的。
    • 极端的说，基于LSM树实现的HBase的写性能比MySQL高了一个数量级，读性能低了一个数量级。
    • 优化方式：Bloom filter 替代二分查找；compact 小数位大树，提高查询性能。
    • Hbase 中，内存中达到一定阈值后，整体flush到磁盘上、形成一个文件（B+数），HDFS不支持update操作，所以Hbase做整体flush而不是merge update。flush到磁盘上的小树，定期会合并成一个大树。

经常用于大规模数据的排重检查。

  • 每一趟从待排序的记录中选出最小的元素，顺序放在已排好序的序列最后，直到全部记录排序完毕。

  • 相邻元素前后交换、把最大的排到最后。

  • 一侧比另外一次都大或小。

  • 分而治之，分成小份排序，在合并(重建一个新空间进行复制)。

  • 排序过程就是构建最大堆的过程，最大堆：每个结点的值都大于或等于其左右孩子结点的值，堆顶元素是最大值。

  • 和桶排序过程比较像，差别在于桶的数量。

  • 桶排序将[0,1)区间划分为n个相同的大小的子区间，这些子区间被称为桶。
  • 每个桶单独进行排序，然后再遍历每个桶。

按照个位、十位、百位、...依次来排。

  • 要求待查找的序列有序。

Java 中的排序工具

  • Arrays.sort() 采用了2种排序算法 -- 基本类型数据使用快速排序法，对象数组使用归并排序。

常用于大数据的排重，比如email，url 等。 核心原理：将每条数据通过计算产生一个指纹（一个字节或多个字节，但一定比原始数据要少很多），其中每一位都是通过随机计算获得，在将指纹映射到一个大的按位存储的空间中。注意：会有一定的错误率。 优点：空间和时间效率都很高。 缺点：随着存入的元素数量增加，误算率随之增加。

KMP：Knuth-Morris-Pratt算法（简称KMP） 核心原理是利用一个“部分匹配表”，跳过已经匹配过的元素。

  • 未提交读：一个事务可以读取另一个未提交的数据，容易出现脏读的情况。

  • 读提交：一个事务等另外一个事务提交之后才可以读取数据，但会出现不可重复读的情况（多次读取的数据不一致），读取过程中出现UPDATE操作，会多。（大多数数据库默认级别是RC，比如SQL Server，Oracle），读取的时候不可以修改。

  • 可重复读： 同一个事务里确保每次读取的时候，获得的是同样的数据，但不保障原始数据被其他事务更新（幻读），Mysql InnoDB 就是这个级别。

  • 序列化：所有事物串行处理（牺牲了效率）

    • 图解脏读、不可重复读、幻读问题。

  • MVCC 会产生幻读问题（更新时异常。）
    • 通过隐藏版本列来实现 MVCC 控制，一列记录创建时间、一列记录删除时间，这里的时间
    • 每次只操作比当前版本小（或等于）的 行。

Java中的锁和同步类

    • 简单的说 就是Mutex是排它的，只有一个可以获取到资源， Semaphore也具有排它性，但可以定义多个可以获取的资源的对象。

公平锁的作用就是严格按照线程启动的顺序来执行的，不允许其他线程插队执行的；而非公平锁是允许插队的。

悲观锁如果使用不当（锁的条数过多），会引起服务大面积等待。推荐优先使用乐观锁+重试。

    • 乐观锁的方式：版本号+重试方式
    • mysql的innodb存储引擎实务锁虽然是锁行，但它内部是锁索引的。
    • 锁相同数据的不同索引条件可能会引起死锁。

    • 和MySQL乐观锁方式相似，只不过是通过和原值进行比较。

由于高并发，在CAS下，更新后可能此A非彼A。通过版本号可以解决，类似于上文Mysql 中提到的的乐观锁。

可以对CopyOnWrite容器进行并发的读，而不需要加锁。CopyOnWrite并发容器用于读多写少的并发场景。比如白名单，黑名单，商品类目的访问和更新场景，不适合需要数据强一致性的场景。

    • 实现读写分离，读取发生在原始数据上，写入发生在副本上。
    • 不用加锁，通过最终一致实现一致性。

可重入锁 & 不可重入锁

    • 通过简单代码举例说明可重入锁和不可重入锁。
    • 可重入锁指同一个线程可以再次获得之前已经获得的锁。
    • 可重入锁可以用户避免死锁。
    • synchronized 使用方便，编译器来加锁，是非公平锁。
    • ReenTrantLock 使用灵活，锁的公平性可以定制。

互斥锁：同时只能有一个线程获得锁。比如，ReentrantLock 是互斥锁，ReadWriteLock 中的写锁是互斥锁。 共享锁：可以有多个线程同时或的锁。比如，Semaphore、CountDownLatch 是共享锁，ReadWriteLock 中的读锁是共享锁。

    • 互斥、持有、不可剥夺、环形等待。

典型的 CPU 有三级缓存，距离核心越近，速度越快，空间越小。L1 一般 32k，L2 一般 256k，L3 一般12M。内存速度需要200个 CPU 周期，CPU 缓存需要1个CPU周期。

    • 线程的调度是由操作系统负责，协程调度是程序自行负责
    • 与线程相比，协程减少了无谓的操作系统切换.
    • 实际上当遇到IO操作时做切换才更有意义，（因为IO操作不用占用CPU），如果没遇到IO操作，按照时间片切换.

    • 开闭原则：对扩展开放,对修改关闭，多使用抽象类和接口。
    • 里氏替换原则：基类可以被子类替换，使用抽象类继承,不使用具体类继承。
    • 依赖倒转原则：要依赖于抽象,不要依赖于具体，针对接口编程,不针对实现编程。
    • 接口隔离原则：使用多个隔离的接口,比使用单个接口好，建立最小的接口。
    • 迪米特法则：一个软件实体应当尽可能少地与其他实体发生相互作用，通过中间类建立联系。
    • 合成复用原则：尽量使用合成/聚合,而不是使用继承。

    • 桥接模式：这个模式将抽象和抽象操作的实现进行了解耦，这样使得抽象和实现可以独立地变化，如JDBC；
    • 组合模式：使得客户端看来单个对象和对象的组合是同等的。换句话说，某个类型的方法同时也接受自身类型作为参数，如 Map.putAll，List.addAll、Set.addAll。
  • 享元模式：使用缓存来加速大量小对象的访问时间，如 valueOf(int)。
  • 代理模式：代理模式是用一个简单的对象来代替一个复杂的或者创建耗时的对象，如 java.lang.reflect.Proxy
    • 抽象工厂模式：抽象工厂模式提供了一个协议来生成一系列的相关或者独立的对象，而不用指定具体对象的类型，如 java.util.Calendar#getInstance()。
    • 责任链模式：通过把请求从一个对象传递到链条中下一个对象的方式，直到请求被处理完毕，以实现对象间的解耦。如 javax.servlet.Filter#doFilter()。
    • 命令模式：将操作封装到对象内，以便存储，传递和返回，如：java.lang.Runnable。
  • 迭代器模式：提供一个一致的方法来顺序访问集合中的对象，如 java.util.Iterator。
  • 中介者模式：通过使用一个中间对象来进行消息分发以及减少类之间的直接依赖，java.lang.reflect.Method#invoke()。
  • 观察者模式：它使得一个对象可以灵活的将消息发送给感兴趣的对象，如 java.util.EventListener。
  • 模板方法模式：让子类可以重写方法的一部分，而不是整个重写，如 java.util.Collections#sort()。

    • 正向控制：传统通过new的方式。反向控制，通过容器注入对象。
  • DI：Dependency Injection，即依赖注入，只关心资源使用，不关心资源来源。

    • Spring AOP使用的动态代理，主要有两种方式：JDK动态代理和CGLIB动态代理。
    • Spring AOP 框架对 AOP 代理类的处理原则是：如果目标对象的实现类实现了接口，Spring AOP 将会采用 JDK 动态代理来生成 AOP 代理类；如果目标对象的实现类没有实现接口，Spring AOP 将会采用 CGLIB 来生成 AOP 代理类

    • 定律一：组织沟通方式会通过系统设计表达出来，就是说架构的布局和组织结构会有相似。
    • 定律二：时间再多一件事情也不可能做的完美，但总有时间做完一件事情。一口气吃不成胖子，先搞定能搞定的。
    • 定律三：线型系统和线型组织架构间有潜在的异质同态特性。种瓜得瓜，做独立自治的子系统减少沟通成本。
    • 定律四：大的系统组织总是比小系统更倾向于分解。合久必分，分而治之。

    • 监控的方式：主动、被动、旁路(比如舆情监控)
    • 监控类型： 基础监控、服务端监控、客户端监控、 监控、用户端监控
    • 监控的目标：全、块、准
    • 核心指标：请求量、成功率、耗时

  • 主要开源软件，按字母排序

    • 主要基于 Google的Dapper（大规模分布式系统的跟踪系统） 思想。

    • 常用指标：访问与访客、停留时长、跳出率、退出率、转化率、参与度
    • 第三方统计：友盟、百度移动、魔方、App Annie、talking data、神策数据等。
    • 所谓无痕、即通过可视化工具配置采集节点，在前端自动解析配置并上报埋点数据，而非硬编码。

开发、测试、生成环境分离。

  • 好处：一次关注一个点，降低思维负担；迎接需求变化或改善代码的设计；提前澄清需求；快速反馈；

    • TestNG 覆盖 JUnit 功能，适用于更复杂的场景。
    • 模块接口测试、局部数据结构测试、路径测试 、错误处理测试、边界条件测试 。

A/B 、灰度、蓝绿测试

    • Nginx 通过异步非阻塞的事件处理机制实现高并发。Apache 每个请求独占一个线程，非常消耗系统资源。
    • 事件驱动适合于IO密集型服务(Nginx)，多进程或线程适合于CPU密集型服务(Apache)，所以Nginx适合做反向代理，而非web服务器使用。
    • nginx只适合静态和反向代理，不适合处理动态请求。

    • 通过 Lua 模块可以在Nginx上进行开发。

    • Tomcat 是轻量级的 Serverlet 容器，没有实现全部 JEE 特性（比如持久化和事务处理），但可以通过其他组件代替，比如Spring。
    • Jboss 实现全部了JEE特性，软件开源免费、文档收费。
    • 启动NIO模式（或者APR）；调整线程池；禁用AJP连接器（Nginx+tomcat的架构，不需要AJP）；
    • AJP 协议（8009端口）用于降低和前端Server（如Apache，而且需要支持AJP协议）的连接数(前端)，通过长连接提高性能。
    • 并发高时，AJP协议优于HTTP协议。

    • 架构比较:Jetty的架构比Tomcat的更为简单。
    • 性能比较：Jetty和Tomcat性能方面差异不大，Jetty默认采用NIO结束在处理I/O请求上更占优势，Tomcat默认采用BIO处理I/O请求，Tomcat适合处理少数非常繁忙的链接，处理静态资源时性能较差。
    • 其他方面：Jetty的应用更加快速，修改简单，对新的Servlet规范的支持较好;Tomcat 对JEE和Servlet 支持更加全面。

    • 堆内、堆外、磁盘三级缓存。
    • 可按照缓存空间容量进行设置。
    • 按照时间、次数等过期策略。
    • 简单轻量、无堆外、磁盘缓存。

    • 采用多路复用技术提高并发性。
    • slab分配算法： memcached给Slab分配内存空间，默认是1MB。分配给Slab之后 把slab的切分成大小相同的chunk，Chunk是用于缓存记录的内存空间，Chunk 的大小默认按照1.25倍的速度递增。好处是不会频繁申请内存，提高IO效率，坏处是会有一定的内存浪费。
    • 区别在于当key存在还是不存在时，返回值是true和false的。

    • 使用 ziplist 存储链表，ziplist是一种压缩链表，它的好处是更能节省内存空间，因为它所存储的内容都是在连续的内存区域当中的。
    • 使用 skiplist(跳跃表)来存储有序集合对象、查找上先从高Level查起、时间复杂度和红黑树相当，实现容易，无锁、并发性好。
    • RDB方式：定期备份快照，常用于灾难恢复。优点：通过fork出的进程进行备份，不影响主进程、RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。缺点：会丢数据。
    • AOF方式：保存操作日志方式。优点：恢复时数据丢失少，缺点：文件大，回复慢。

  • 特点：可以配置备份节点数目，通过异步同步到备份节点
  • MDB，完全内存性，可以用来存储Session等数据。
  • Rdb（类似于Redis），轻量化，去除了aof之类的操作，支持Restfull操作
  • LDB（LevelDB存储引擎），持久化存储，LDB 作为rdb的持久化，google实现，比较高效，理论基础是LSM(Log-Structured-Merge Tree)算法，现在内存中修改数据，达到一定量时（和内存汇总的旧数据一同写入磁盘）再写入磁盘，存储更加高效，县比喻Hash算法。
  • Tair采用共享内存来存储数据，如果服务挂掉（非服务器），重启服务之后，数据亦然还在。

    • RabbitMQ 消费者默认是推模式（也支持拉模式）。
    • Kafka 默认是拉模式。
    • Push方式：优点是可以尽可能快地将消息发送给消费者，缺点是如果消费者处理能力跟不上，消费者的缓冲区可能会溢出。
    • Pull方式：优点是消费端可以按处理能力进行拉去，缺点是会增加消息延迟。

消息总线相当于在消息队列之上做了一层封装，统一入口，统一管控、简化接入成本。

支持事务，推拉模式都是支持、适合需要可靠性消息传输的场景。

Java实现，推拉模式都是支持，吞吐量逊于Kafka。可以保证消息顺序。

纯Java实现，兼容JMS，可以内嵌于Java应用中。

高吞吐量、采用拉模式。适合高IO场景，比如日志同步。

生产者、消费者模式完全是客户端行为，list 和 拉模式实现，阻塞等待采用 blpop 指令。

    • 定时调度在 QuartzSchedulerThread 代码中，while()无限循环，每次循环取出时间将到的trigger，触发对应的job，直到调度器线程被关闭。

    • Quartz集群中，独立的Quartz节点并不与另一其的节点或是管理节点通信，而是通过相同的数据库表来感知到另一Quartz应用的

    • 核心角色：Server: 暴露服务的服务提供方、Client: 调用远程服务的服务消费方、Registry: 服务注册与发现的注册中心。

    • 支持多语言，通过中间语言定义接口。

服务端可以认证加密，在外网环境下，可以保证数据安全。

  • 支持推、拉模式更新配置

servlet 3.0 异步特性可用于配置中心的客户端

主要职责：请求转发、安全认证、协议转换、容灾。

    • 利用二进制帧负责传输。

    • 使用非对称加密协商加密算法
    • 使用对称加密方式传输数据
    • 使用第三方机构签发的证书，来加密公钥，用于公钥的安全传输、防止被中间人串改。

    • 五种I/O模型：阻塞I/O，非阻塞I/O，I/O复用、事件(信号)驱动I/O、异步I/O，前四种I/O属于同步操作，I/O的第一阶段不同、第二阶段相同，最后的一种则属于异步操作。
    • select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的。
    • select 有打开文件描述符数量限制，默认1024（2048 for x64），100万并发，就要用1000个进程、切换开销大；poll采用链表结构，没有数量限制。
    • select，poll “醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，通过回调机制节省大量CPU时间；select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，而epoll只要一次拷贝。
    • poll会随着并发增加，性能逐渐下降，epoll采用红黑树结构，性能稳定，不会随着连接数增加而降低。
    • 在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。
    • NIO 是一种同步非阻塞的 IO 模型。同步是指线程不断轮询 IO 事件是否就绪，非阻塞是指线程在等待 IO 的时候，可以同时做其他任务

    • 多个物理分离的buffer，通过逻辑上合并成为一个，从而避免了数据在内存之间的拷贝。

  •  Goolge出品、占用空间和效率完胜其他序列化类库，如Hessian；需要编写 .proto 文件。

    • 关于协议的解释；缺点：可读性差;

    • 第一范式：数据表中的每一列（每个字段）必须是不可拆分的最小单元，也就是确保每一列的原子性；
    • 第二范式（2NF）：满足1NF后，要求表中的所有列，都必须依赖于主键，而不能有任何一列与主键没有关系，也就是说一个表只描述一件事情；
    • 第三范式：必须先满足第二范式（2NF），要求：表中的每一列只与主键直接相关而不是间接相关，（表中的每一列只能依赖于主键）；

    • 两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁

    • 原则上就是缩小扫描范围。

聚集索引, 非聚集索引

  • 原文中提到索引是按照“col1，col2，col3”的顺序创建的，而mysql在按照最左前缀的索引匹配原则，且会自动优化 where 条件的顺序，当条件中只有 col2=B AND col1=A 时，会自动转化为 col1=A AND col2=B，所以依然会使用索引。

自适应哈希索引(AHI)

    • 优点：弱一致性（最终一致），更能保证用户的访问速度；内置GridFS，支持大容量的存储；Schema-less 数据库，不用预先定义结构；内置Sharding；相比于其他NoSQL，第三方支持丰富；性能优越；
    • 缺点：mongodb不支持事务操作；mongodb占用空间过大；MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方；

    • 空数据不存储，节省空间，且适用于并发。
    • rowkey 按照字典顺序排列，便于批量扫描。
    • 通过散列可以避免热点。

    • 代码层面、业务层面、数据库层面、服务器层面、前端优化。

    • 评估总访问量、评估平均访问量QPS、评估高峰QPS、评估系统、单机极限QPS

  • 推荐系统用户画像标签实时更新；
  • 线上服务健康状况实时监测；

    • 滑动验证码是根据人在滑动滑块的响应时间，拖拽速度，时间，位置，轨迹，重试次数等来评估风险。

  1. 用户密码非明文保存，加动态salt。
  2. 身份证号，手机号如果要显示，用 “*” 替代部分字符。
  3. 联系方式在的显示与否由用户自己控制。

  • DES 秘钥太短（只有56位）算法目前已经被 AES 取代，并且 AES 有硬件加速，性能很好。

    • MD5 和 SHA-1 已经不再安全，已被弃用。

    • 和 RSA 不同的是 DSA 仅能用于数字签名，不能进行数据加密解密，其安全性和RSA相当，但其性能要比RSA快。

    • 256位的ECC秘钥的安全性等同于3072位的RSA秘钥。

在内外环境中通过跳板机登录到线上主机。

常用做法是 登录密码 + 手机验证码（或者令牌Key，类似于与网银的 USB key）

  • 【《双因素认证（2FA）教程》】()

    • Log4J 异步日志性能优异。

    • 主要目的是为了提高开发效率。
    • 一级缓存是SqlSession级别的缓存，缓存的数据只在SqlSession内有效
    • 二级缓存是mapper级别的缓存，同一个namespace公用这一个缓存，所以对SqlSession是共享的；使用 LRU 机制清理缓存，通过 cacheEnabled 参数开启。

    • 总结下来，通用的套路就是分布、缓存及异步处理。
  • 利用中间件进行分片如，MySQL Proxy。
  • 利用分片策略进行切分，如按照ID取模。
    • 分布式服务+消息队列。

    • 可扩展：水平扩展、垂直扩展。 通过冗余部署，避免单点故障。
    • 隔离：避免单一业务占用全部资源。避免业务之间的相互影响 2. 机房隔离避免单点故障。
    • 解耦：降低维护成本，降低耦合风险。减少依赖，减少相互间的影响。
    • 限流：滑动窗口计数法、漏桶算法、令牌桶算法等算法。遇到突发流量时，保证系统稳定。
    • 降级：紧急情况下释放非核心功能的资源。牺牲非核心业务，保证核心业务的高可用。
    • 熔断：异常情况超出阈值进入熔断状态，快速失败。减少不稳定的外部依赖对核心服务的影响。
    • 自动化测试：通过完善的测试，减少发布引起的故障。
    • 灰度发布：灰度发布是速度与安全性作为妥协，能够有效减少发布故障。
    • 设计原则：数据不丢(持久化)；服务高可用(服务副本)；绝对的100%高可用很难，目标是做到尽可能多的9，如99.999%（全年累计只有5分钟）。

  •  轮寻、权重、负载、最少连接、QoS

    • 配置简单，更新速度慢。
    • 简单轻量、学习成本低；主要适用于web应用。
    • 配置比较负载、只支持到4层，性能较高。
    • 支持到七层（比如HTTP）、功能比较全面，性能也不错。
    • 主要是用户读请求的负载均衡。

    • 计数器：通过滑动窗口计数器，控制单位时间内的请求次数，简单粗暴。
    • 漏桶算法：固定容量的漏桶，漏桶满了就丢弃请求，比较常用。
    • 令牌桶算法：固定容量的令牌桶，按照一定速率添加令牌，处理请求前需要拿到令牌，拿不到令牌则丢弃请求，或进入丢队列，可以通过控制添加令牌的速率，来控制整体速度。Guava 中的 RateLimiter 是令牌桶的实现。

    • 雪崩效应原因：硬件故障、硬件故障、程序Bug、重试加大流量、用户大量请求。
    • 雪崩的对策：限流、改进缓存模式(缓存预加载、同步调用改异步)、自动扩容、降级。
      • 资源隔离：Hystrix通过将每个依赖服务分配独立的线程池进行资源隔离, 从而避免服务雪崩。
      • 熔断开关：服务的健康状况 = 请求失败数 / 请求总数，通过阈值设定和滑动窗口控制开关。
      • 命令模式：通过继承 HystrixCommand 来包装服务调用逻辑。
    • 主要策略：失效瞬间：单机使用锁；使用分布式锁；不过期；
    • 热点数据：热点数据单独存储；使用本地缓存；分成多个子key；

    • 通过自研中间件进行数据同步。
    • 注意延迟问题，多次跨机房调用会将延时放大数倍。
    • 建房间专线很大概率会出现问题，做好运维和程序层面的容错。
    • 不能依赖于程序端数据双写，要有自动同步方案。
    • 数据永不在高延迟和较差网络质量下，考虑同步质量问题。
    • 核心业务和次要业务分而治之，甚至只考虑核心业务。
    • 异地多活监控部署、测试也要跟上。
    • 业务允许的情况下考虑用户分区，尤其是游戏、邮箱业务。
    • 控制跨机房消息体大小，越小越好。
    • 考虑使用docker容器虚拟化技术，提高动态调度能力。

  • 案例：预案有效性、预案有效性、故障复现、架构容灾测试、参数调优、参数调优、故障突袭、联合演练。

  • 平滑重启应用思路 1.端流量（如vip层）、2. flush 数据(如果有)、3, 重启应用

    • DRDB 进行磁盘复制，避免单点问题。

  • 问题：事务、Join、迁移、扩容、ID、分页等。
  • 事务补偿：对数据进行对帐检查;基于日志进行比对;定期同标准数据来源进行同步等。
  • 分库策略：数值范围；取模；日期等。
  • 分库数量：通常 MySQL 单库 5千万条、Oracle 单库一亿条需要分库。
    • 分区：是MySQL内部机制，对客户端透明，数据存储在不同文件中，表面上看是同一个表。
    • 分表：物理上创建不同的表、客户端需要管理分表路由。

    • 客户端服务发现模式：客户端直接查询注册表，同时自己负责负载均衡。Eureka 采用这种方式。
    • 服务器端服务发现模式：客户端通过负载均衡查询服务实例。
    • 优点：API简单、Pinterest，Airbnb 在用、多语言、通过watcher机制来实现配置PUSH，能快速响应配置变化。

  • 负载均衡策略：随机、轮询、服务调用延迟、一致性哈希、粘滞连接
  • 本地路由有限策略：injvm(优先调用jvm内部的服务)，innative(优先使用相同物理机的服务),原则上找距离最近的服务。
  • 配置方式：统一注册表；本地配置；动态下发。

    • 一致性分类：强一致(立即一致)；弱一致(可在单位时间内实现一致，比如秒级)；最终一致(弱一致的一种，一定时间内最终一致)
    • CAP：一致性、可用性、分区容错性(网络故障引起)
  • BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

    • 基于数据库的分布式锁：优点：操作简单、容易理解。缺点：存在单点问题、数据库性能够开销较大、不可重入；
    • 基于缓存的分布式锁：优点：非阻塞、性能好。缺点：操作不好容易造成锁无法释放的情况。
    • Zookeeper 分布式锁：通过有序临时节点实现锁机制，自己对应的节点需要最小，则被认为是获得了锁。优点：集群可以透明解决单点问题，避免锁不被释放问题，同时锁可以重入。缺点：性能不如缓存方式，吞吐量会随着zk集群规模变大而下降。
    • 清楚的原理描述 + Java 代码示例。

  • 通过随机等待的方式发出投票，得票多的获胜。

两阶段提交、多阶段提交

    • 幂等特性的作用：该资源具备幂等性，请求方无需担心重复调用会产生错误。
    • 常见保证幂等的手段：MVCC（类似于乐观锁）、去重表(唯一索引)、悲观锁、一次性token、序列号方式。

    • 基于BASE理论：基本可用、柔性状态、最终一致。
    • 解决方案：记录日志+补偿（正向补充或者回滚）、消息重试(要求程序要幂等)；“无锁设计”、采用乐观锁机制。

    • HDFS：大批量数据读写，用于高吞吐量的场景，不适合小文件。
    • FastDFS：轻量级、适合小文件。

    • Twitter 方案（Snowflake 算法）：41位时间戳+10位机器标识（比如IP，服务器名称等）+12位序列号(本地计数器)
  • UUID：缺点，无序，字符串过长，占用空间，影响检索性能。
    • 在数据库中创建 sequence 表，用于记录，当前已被占用的id最大值。
    • 每台客户端主机取一个id区间（比如 ）缓存在本地，并更新 sequence 表中的id最大值记录。
    • 客户端主机之间取不同的id区间，用完再取，使用乐观锁机制控制并发。

    • 概念：DDD 主要对传统软件开发流程(分析-设计-编码)中各阶段的割裂问题而提出，避免由于一开始分析不明或在软件开发过程中的信息流转不一致而造成软件无法交付（和需求方设想不一致）的问题。DDD 强调一切以领域（Domain）为中心，强调领域专家（Domain Expert）的作用，强调先定义好领域模型之后在进行开发，并且领域模型可以指导开发（所谓的驱动）。
    • 过程：理解领域、拆分领域、细化领域，模型的准确性取决于模型的理解深度。
    • 设计：DDD 中提出了建模工具，比如聚合、实体、值对象、工厂、仓储、领域服务、领域事件来帮助领域建模。
    • 领域（Doamin）本质上就是问题域，比如一个电商系统，一个论坛系统等。
    • 界限上下文（Bounded Context）：阐述子域之间的关系，可以简单理解成一个子系统或组件模块。
    • 领域模型（Domain Model）：DDD的核心是建立（用通用描述语言、工具—领域通用语言）正确的领域模型；反应业务需求的本质，包括实体和过程；其贯穿软件分析、设计、开发 的整个过程；常用表达领域模型的方式：图、代码或文字；
    • 领域通用语言：领域专家、开发设计人员都能立即的语言或工具。
    • 经典分层架构：用户界面/展示层、应用层、领域层、基础设施层，是四层架构模式。
      • 关联尽量少，尽量单项，尽量降低整体复杂度。
      • 实体（Entity）：领域中的唯一标示，一个实体的属性尽量少，少则清晰。
      • 值对象（Value Object）：没有唯一标识，且属性值不可变，小二简单的对象，比如Date。
      • 领域服务（Domain Service）： 协调多个领域对象，只有方法没有状态(不存数据)；可以分为应用层服务，领域层服务、基础层服务。
        • Root）：聚合定义了一组具有内聚关系的相关对象的集合；聚合根是对聚合引用的唯一元素；当修改一个聚合时，必须在事务级别；大部分领域模型中，有70%的聚合通常只有一个实体，30%只有2~3个实体；如果一个聚合只有一个实体，那么这个实体就是聚合根；如果有多个实体，那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互；
  • 工厂（Factory）：类似于设计模式中的工厂模式。
  • 仓储（Repository）：持久化到DB，管理对象，且只对聚合设计仓储。
    • 聚合：比如一辆汽车（Car）包含了引擎（Engine）、车轮（Wheel）和油箱（Tank）等组件，缺一不可。

命令查询职责分离(CQRS)

    • 核心思想：读写分离（查询和更新在不同的方法中），不同的流程只是不同的设计方式，CQ代码分离，分布式环境中会有明显体现（有冗余数据的情况下），目的是为了高性能。
    • 最终一致的设计理念；依赖于高可用消息中间件。
    • 一个实现 CQRS 的抽象案例。

    • 失血模型：老子和儿子分别定义，相互不知道，二者实体定义中完全没有业务逻辑，通过外部Service进行关联。
    • 贫血模型：老子知道儿子，儿子也知道老子；部分业务逻辑放到实体中；优点：各层单项依赖，结构清楚，易于维护；缺点：不符合OO思想，相比于充血模式，Service层较为厚重；
    • 充血模型：和贫血模型类似，区别在于如何划分业务逻辑。优点：Service层比较薄，只充当Facade的角色，不和DAO打交道、复合OO思想；缺点：非单项依赖，DO和DAO之间双向依赖、和Service层的逻辑划分容易造成混乱。
    • 肿胀模式：是一种极端情况，取消Service层、全部业务逻辑放在DO中；优点：符合OO思想、简化了分层；缺点：暴露信息过多、很多非DO逻辑也会强行并入DO。这种模式应该避免。
    • 作者主张使用贫血模式。

无需过多关系服务器的服务架构理念。

    • Serverless 不代表出去服务器，而是去除对服务器运行状态的关心。
    • Serverless 代表一思维方式的转变，从“构建一套服务在一台服务器上，对对个事件进行响应转变为构建一个为服务器，来响应一个事件”。

制度还是制度! 另外，每个公司需要根据自己的需求和目标制定自己的 check list

    • 代码 review 做的好，在于制度建设。

  • 五个价值观：专注、勇气、公开、承诺、尊重。

    • 是一种指导开发人员的方法论。

      • 沟通：鼓励口头沟通，提高效率。
    • 反馈：及时反馈、通知相关人。
    • 勇气：提倡拥抱变化，敢于重构。

  • 5个原则：快速反馈、简单性假设、逐步修改、提倡更改（小步快跑）、优质工作（保证质量的前提下保证小步快跑）。

  • 5个工作：阶段性冲刺；冲刺计划会议；每日站立会议；冲刺后review；回顾会议。

边写码，边review。能够增强代码质量、减少bug。

PDCA 循环质量管理

严格遵守刑法253法条

我国刑法第253条之一规定：

  • 国家机关或者金融、电信、交通、教育、医疗等单位的工作人员，违反国家规定，将本单位在履行职责或者提供服务过程中获得的公民个人信息，出售或者非法提供给他人，情节严重的，处3年以下有期徒刑或者拘役，并处或者单处罚金。
  • 窃取或者以其他方法非法获取上述信息，情节严重的，依照前款的规定处罚。
  • 单位犯前两款罪的，对单位判处罚金，并对其直接负责的主管人员和其他直接责任人员，依照各该款的规定处罚。

最高人民法院、最高人民检察院关于执行《中华人民共和国刑法》确定罪名的补充规定（四）规定：触犯刑法第253条之一第1款之规定，构成“出售、非法提供公民个人信息罪”；触犯刑法第253条之一第2款之规定，构成“非法获取公民个人信息罪”

  • 全面：1. 在面对业务问题上，架构师脑海里是否会浮现出多种技术方案；2. 在做系统设计时是否考虑到了足够多的方方面面；3. 在做系统设计时是否考虑到了足够多的方方面面；
  • 全局：是否考虑到了对上下游的系统的影响。
  • 权衡：权衡投入产出比；优先级和节奏控制；
    • 要去考虑的细节：模块化、轻耦合、无共享架构；减少各个组件之前的依赖、注意服务之间依赖所有造成的链式失败及影响等。
    • 基础设施、配置、测试、开发、运维综合考虑。
    • 考虑人、团队、和组织的影响。
    • 素质：业务理解、技术广度、技术深度、丰富经验、沟通能力、动手能力、美学素养。
    • 成长路径：2年积累知识、4年积累技能和组内影响力、7年积累部门内影响力、7年以上积累跨部门影响力。
    • 第一层的架构师看到的只是产品本身
    • 第二层的架构师不仅看到自己的产品，还看到了整体的方案
    • 第三层的架构师看到的是商业价值

  •  老牌技术社区、不必解释。

    • 涵盖 IT职场、Web前端、后端、移动端、数据库等方面内容，偏技术端。

      • 专注于 Java 技术分享
      • 偏重于基础架构、运维方向
      • 专注于 Docker 应用及咨询、教程的网站

  • 《阿里巴巴Java开发手册》

  • 《软件架构师的12项修炼：技术技能篇》

  • 《云原生应用架构实践》

  • 《亿级流量网站架构核心技术》

  • 《企业IT架构转型之道-中台战略思想与架构实战》 

  • 《高可用架构（第1卷）》

  • 《网易一千零一夜：互联网产品项目管理实战》

    • 很多很多中文在线电子书，是一个全新的开源技术文档分享平台。
    • AI、大数据方面系列中文文档。
    • 知名教程网站，提供Java、Python、JS、SQL、大数据等高质量入门教程。

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进

    • 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本
    • 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键
    • 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率
    • 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求
    • 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键
        • 每次发布只部署部分服务器
        • 每个节点可根据不同需求伸缩扩展
        • 每个应用之间更新，部署，运行不影响
      • 停止RPC滥用，垂直业务内优先通过本地jar调用，跨业务才采用RPC调用
      • 正确的识别业务逻辑的归属，让各个模块最大化内聚，从性能，可用性和维护性上减少耦合
    • 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率
    • 此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键

在大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡

  • 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大
    • 此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明
    • 并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本
  • 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系
    • 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系
  • 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
    • 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标
    • 其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量
    • proxy（服务代理层）
      • 服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton
    • 封装服务地址的注册与发现
    • 支持基于网络的集群方式，有广泛周边开源产品，建议使用dubbo-2.3.3以上版本（推荐使用）
    • 支持基于客户端双写的集群方式，性能高
    • 要求服务器时间同步，用于检查心跳过期脏数据
    • 去中心化，不需要安装注册中心
    • 依赖于网络拓普和路由，跨机房有风险
    • Dogfooding，注册中心本身也是一个标准的RPC服务
    • 没有集群支持，可能单点故障
    • 封装多个提供者的路由及负载均衡，并桥接注册中心
    • 失败自动切换，当出现失败，重试其它服务器，通常用于读操作（推荐使用）
    • 快速失败，只发起一次调用，失败立即报错,通常用于非幂等性的写操作
    • 如果有机器正在重启，可能会出现调用失败
    • 失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作
    • 失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作
    • 并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作
    • 广播调用所有提供者，逐个调用，任意一台报错则报错，通常用于更新提供方本地状态
    • 速度慢，任意一台报错则报错
      • 随机，按权重设置随机概率（推荐使用）
      • 在一个截面上碰撞的概率高，重试时，可能出现瞬间压力不均
      • 轮循，按公约后的权重设置轮循比率
      • 存在慢的机器累积请求问题，极端情况可能产生雪崩
      • 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差，使慢的机器收到更少请求
      • 不支持权重，在容量规划时，不能通过权重把压力导向一台机器压测容量
      • 一致性Hash，相同参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动
      • 基于条件表达式的路由规则，功能简单易用
      • 有些复杂多分支条件情况，规则很难描述
      • 基于脚本引擎的路由规则，功能强大
      • 没有运行沙箱，脚本能力过于强大，可能成为后门
    • 启动一个内嵌Jetty，用于汇报状态
    • 大量访问页面时，会影响服务器的线程和内存
    • 自动配置log4j的配置，在多进程启动时，自动给日志文件按进程分目录
    • 用户不能控制log4j的配置，不灵活
    • RPC调用次数和调用时间监控
      • 采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用）
      • 适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
      • Dubbo缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低
      • Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接
      • 为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护
      • 在大文件传输时，单一连接会成为瓶颈
  • 传输方式：NIO异步传输
  • 序列化：Hessian二进制序列化
  • 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
  • 适用场景：常规远程服务方法调用
    • 可与原生RMI互操作，基于TCP协议
    • 偶尔会连接失败，需重建Stub
    • 可与原生Hessian互操作，基于HTTP协议
  • 可以和原生Hessian服务互操作
    • 提供者用Dubbo的Hessian协议暴露服务，消费者直接用标准Hessian接口调用
    • 或者提供方用标准Hessian暴露服务，消费方用Dubbo的Hessian协议调用
    • 基于Hessian的远程调用协议
  • 序列化：Hessian二进制序列化
  • 适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件
  • 适用场景：页面传输，文件传输，或与原生hessian服务互操作
  • 参数及返回值不能自定义实现List, Map, Number, Date, Calendar等接口，只能用JDK自带的实现，因为hessian会做特殊处理，自定义实现类中的属性值都会丢失
    • 封装请求响应模式，同步转异步
    • 一次请求派发两种事件，需屏蔽无用事件
  • 待发送消息队列派发不及时，大压力下，会出现FullGC
  • 线程池不可扩展，Filter不能拦截下一Filter
      • 性能较好，多语言支持（推荐使用）
    • 通过不传送POJO的类元信息，在大量POJO传输时，性能较好
    • 当参数对象增加字段时，需外部文件声明
    • 纯文本，可跨语言解析，缺省采用FastJson解析
  • 而Cluster是外围概念，所以Cluster的目的是将多个Invoker伪装成一个Invoker，这样其它人只要关注Protocol层Invoker即可，加上Cluster或者去掉Cluster对其它层都不会造成影响，因为只有一个提供者时，是不需要Cluster的。
  • Proxy层封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
  • Registry和Monitor实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起
    • dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。
    • dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
    • dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
    • dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
    • dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。
    • container为服务容器，用于部署运行服务，没有在层中画出。
    • protocol层和proxy层都放在rpc模块中，这两层是rpc的核心，在不需要集群时(只有一个提供者)，可以只使用这两层完成rpc调用。
    • Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理
    • Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现
    • Invocation是会话域，它持有调用过程中的变量，比如方法名，参数等
    • 采用Microkernel + Plugin模式，Microkernel只负责组将Plugin，Dubbo自身的功能也是通过扩展点实现的，也就是Dubbo的所有功能点都可被用户自定义扩展所替换
    • 采用URL作为配置信息的统一格式，所有扩展点都通过传递URL携带配置信息
  • 在扩展类的jar包内，放置扩展点配置文件：META-INF/dubbo/接口全限定名，内容为：配置名=扩展实现类全限定名，多个实现类用换行符分隔
  • 注意：这里的配置文件是放在你自己的jar包内，不是dubbo本身的jar包内，Dubbo会全ClassPath扫描所有jar包内同名的这个文件，然后进行合并
    • 具体服务到Invoker的转换
      • 它通过Spring或Dubbo或JDK来实现RMI服务，通讯细节这一块由JDK底层来实现，这就省了不少工作量
    • 把Invoker转为客户端需要的接口
    • 过程：首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例(如上图中的红色部分)，这是服务消费的关键。接下来把Invoker转换为客户端需要的接口
    • 由于Invoker是Dubbo领域模型中非常重要的一个概念，很多设计思路都是向它靠拢
    • 被封装成为一个AbstractProxyInvoker实例，并新生成一个Exporter实例。这样当网络通讯层收到一个请求后，会找到对应的Exporter实例，并调用它所对应的AbstractProxyInvoker实例，从而真正调用了服务提供者的代码
    • all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等
    • direct 所有消息都不派发到线程池，全部在IO线程上直接执行
    • message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在IO线程上执行
    • execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在IO线程上执行
    • connection 在IO线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池
    • fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
    • cached 缓存线程池，空闲一分钟自动删除，需要时重建
    • limited 可伸缩线程池，但池中的线程数只会增长不会收缩。(为避免收缩时突然来了大流量引起的性能问题)
  • 连接控制： 连接数控制
  • 分组聚合： 分组聚合返回值，用于菜单聚合等服务
  • 泛化引用： 泛化调用，无需业务接口类进行远程调用，用于测试平台，开放网关桥接等
  • 延迟暴露： 延迟暴露服务，用于等待应用加载warmup数据，或等待spring加载完成
  • 延迟连接： 延迟建立连接，调用时建立
      • 包中的类应该有同样的重用可能性
      • 紧密协作的类应该放在一个包
      • 对于变化因子，包中的类应全改或全不改
      • 变化应在包内终止，而不传播到其它包
      • 发布的粒度和复用度相同
      • 被依赖的包应该总是比依赖者更稳定
      • 不要让一个稳定的包依赖于不稳定包
      • 稳定的包不抽象将导致扩展性极差
      • 抽象的包不稳定将导致其依赖包跟随变化
    • 平等对待第三方 
        • 框架自己的功能也要扩展点实现
        • 甚至微核的加载方式也可以扩展
        • 装配逻辑由扩展点之间互助完成
        • 杜绝硬编码的桥接和中间代码
        • 层叠扩展粒度，逐级细分
        • 由大的扩展点加载小的扩展点
        • 只与触手可及的扩展点交互，间接转发
        • 保持行为单一，输入输出明确
      • API传入参数，SPI扩展点实例
      • 尽量引用外部对象的实例，而不类元
  • 尽量使用IoC注入，减少静态工厂方法调用
    • 所有配置信息都转换成URL的参数
    • 所有的元信息传输都采用URL
    • 所有接口都可以获取到URL
    • 指产品主要功能入口，同时负责实体域和会话域的生命周期管理。
    • 表示你要操作的对象模型，不管什么产品，总有一个核心概念，大家都绕围它转。
    • 表示每次操作瞬时状态，操作前创建，操作后销毁。
    • 充血模型，实体域带行为
    • 可变与不可变状态分离，可变状态集中
    • 所有领域线程安全，不需要加锁
      • 通常服务域是无状态，或者只有启动时初始化不变状态，所以天生线程安全，只需单一实例运行
      • 通常设计为不变类，所有属性只读，或整个类引用替换，所以是线程安全的
      • 保持所有可变状态，且会话域只在线程栈内使用，即每次调用都在线程栈内创建实例，调用完即销毁，没有竞争，所以线程安全
  • API可配置，一定可编程
    • 命令：无返回值表示命令，有副作用
    • 查询：有返回值表示查询，保持幂等，无副作用
      • 在行为交互为主的系统是适用
      • 在以管理状态为主的系统中适用
    • Web框架的请求响应流
    • 反例：IBatis2在SQL执行过程中没有设拦截点，导致添加安全或日志拦截，执行前修改分页SQL等，不得不hack源代码
    • 保持截面功能单一，不易出问题
  • 确保派发失败，不影响主过程运行
    • 不可靠操作 (尽量缩小)
    • 前置断言 + 后置断言 + 不变式
  • 异常防御，但不忽略异常
  • 降低修改时的误解性，不埋雷
    • 避免基于异常类型的分支流程
  • 软件质量的下降，来源于修改
  • 替换整个实现类，而不是修改其中的某行
  • 增量式 v.s.扩充式
  • 调用两次单向消息发送完成
    • 协议实现，不透明，点对点
    • 将集群中多个提供者伪装成一个
    • 透明化接口，桥接动态代理
    • 尽可能少的依赖低阶契约，用最少的抽象概念实现功能
    • 当低阶切换实现时，高阶功能可以继续复用
    • 尽可能携带完整的上下文信息，比如出错原因，出错的机器地址，调用对方的地址，连的注册中心地址，使用Dubbo的版本等。
    • 尽量将直接原因写在最前面，所有上下文信息，在原因后用键值对显示。
    • 抛出异常的地方不用打印日志，由最终处理异常者决定打印日志的级别，吃掉异常必需打印日志。
    • 打印ERROR日志表示需要报警，打印WARN日志表示可以自动恢复，打印INFO表示正常信息或完全不影响运行。
    • 建议应用方在监控中心配置ERROR日志实时报警，WARN日志每周汇总发送通知。
    • RpcException是Dubbo对外的唯一异常类型，所有内部异常，如果要抛出给用户，必须转为RpcException。
    • RpcException不能有子类型，所有类型信息用ErrorCode标识，以便保持兼容。
    • 配置对象属性首字母小写，多个单词用驼峰命名(Java约定)。
    • 配置属性全部用小写，多个单词用"-"号分隔(Spring约定)。
    • URL参数全部用小写，多个单词用"."号分隔(Dubbo约定)。
    • 尽可能用URL传参，不要自定义Map或其它上下文格式，配置信息也转成URL格式使用。
    • 尽量减少URL嵌套，保持URL的简洁性。
  • 保持单元测试用例的运行速度，不要将性能和大的集成用例放在单元测试中。
  • 减少while循环等待结果的测试用例，对定时器和网络的测试，用以将定时器中的逻辑抽为方法测试。
  • 对于容错行为的测试，比如failsafe的测试，统一用LogUtil断言日志输出。
    • 扩展点之间的组合将关系由AOP完成，ExtensionLoader只负载加载扩展点，包括AOP扩展。
    • 尽量采用IoC注入扩展点之间的依赖，不要直接依赖ExtensionLoader的工厂方法。
    • 尽量采用AOP实现扩展点的通用行为，而不要用基类，比如负载均衡之前的isAvailable检查，它是独立于负载均衡之外的，不需要检查的是URL参数关闭。
    • 对多种相似类型的抽象，用基类实现，比如RMI,Hessian等第三方协议都已生成了接口代理，只需将将接口代理转成Invoker即可完成桥接，它们可以用公共基类实现此逻辑。
    • 基类也是SPI的一部分，每个扩展点都应该有方便使用的基类支持。
    • 基于复用度分包，总是一起使用的放在同一包下，将接口和基类分成独立模块，大的实现也使用独立模块。
    • 所有接口都放在模块的根包下，基类放在support子包下，不同实现用放在以扩展点名字命名的子包下。
    • 尽量保持子包依赖父包，而不要反向。
  • 参考文章“【总结】Netty（RPC高性能之道）原理剖析 ”

软件性能测试之容量测试与容量规划

在性能测试中，需要根据具体的性能需求和系统架构等情况，采用不同的测试策略，其中

最常见的策略就有容量测试。

一、什么是容量？如何理解？

在开始之前，有一点需要知道：

系统的处理能力是有限的

某项指标达到所能接受的最大阈值

①、系统的容量（处理能力）是有限的；

一般来说，可以从如下两个维度来定量系统的容量：

延时超过所能接受的最大时延

磁盘使用率超过最大限制

网络使用率达到上限（最大吞吐量）

我要回帖

更多关于 dubbo负载均衡策略如何配置 的文章

 

随机推荐