goMars的学习随记

微服务治理的手段节点管理1. 注册中心主动摘除机制这种机制要求服务提供者定时的主动向注册中心汇报心跳，注册中心根据服务提供者节点最近一次汇报心跳的时间与上一次汇报心跳时间做比较，如果超出一定时间，就认为服务提供者出现问题，继而把节点从服务列表中摘除，并把最近的可用服务节点列表推送给服务消费者。 2. 服务消费者摘除机制虽然注册中心主动摘除机制可以解决服务提供者节点异常的问题，但如果是因为注册中心与服务提供者之间的网络出现异常，最坏的情况是注册中心会把服务节点全部摘除，导致服务消费者没有可用的服务节点调用，但其实这时候服务提供者本身是正常的。所以，将存活探测机制用在服务消费者这一端更合理，如果服务消费者调用服务提供者节点失败，就将这个节点从内存中保存的可用服务提供者节点列表中移除。 服务节点摘除保护机制 需要根据实际业务的情况，设定一个阈值比例，即使遇到刚才说的这种情况，注册中心也不能摘除超过这个阈值比例的节点。 负载均衡1. 随机算法顾名思义就是从可用的服务节点中随机选取一个节点。一般情况下，随机算法是均匀的，也就是说后端服务节点无论配置好坏，最终得到的调用量都差不多。 2. 轮询 ...

监控微服务调用监控对象监控对象可以分为四个层次，由上到下可归纳为： 用户端监控。通常是指业务直接对用户提供的功能的监控。以微博首页 Feed 为例，它向用户提供了聚合关注的所有人的微博并按照时间顺序浏览的功能，对首页 Feed 功能的监控就属于用户端的监控。 接口监控。通常是指业务提供的功能所依赖的具体 RPC 接口的监控。继续以微博首页 Feed 为例，这个功能依赖于用户关注了哪些人的关系服务，每个人发过哪些微博的微博列表服务，以及每条微博具体内容是什么的内容服务，对这几个服务的调用情况的监控就属于接口监控。 资源监控。通常是指某个接口依赖的资源的监控。比如用户关注了哪些人的关系服务使用的是 Redis 来存储关注列表，对 Redis 的监控就属于资源监控。 基础监控。通常是指对服务器本身的健康状况的监控。主要包括 CPU 利用率、内存使用量、I/O 读写量、网卡带宽等。对服务器的基本监控也是必不可少的，因为服务器本身的健康状况也是影响服务本身的一个重要因素，比如服务器本身连接的网络交换机上联带宽被打满，会影响所有部署在这台服务器上的业务。 监控指标 请求量。请求量监控分为两个维 ...

微服务基础概述微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。 单体应用的痛点： 部署效率低下 团队协作开发成本高 系统高可用性差 线上发布变慢 想要解决上面这些问题，服务化的思想也就应运而生。 用通俗的话来讲，服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。 微服务的优势： 服务拆分粒度更细 服务独立部署 服务独立维护 服务治理能力要求高 总结一下，微服务架构下，主要功能模块： 服务间通信：包括服务治理、负载均衡、服务间调用; 服务容错和异常排查：包括流量整形、降级熔断、调用链追踪; 分布式能力建设：包括微服务网关、分布式事务、消息驱动、分布式配置中心。 服务的发布引用最常见的服务发布和引用的方式有三 ...

Dubbo简介Dubbo是一个开源的、高性能的、广泛应用的远程过程调用（RPC）框架，用于在Java中构建分布式系统。它最初由阿里巴巴集团开发，并作为Apache Dubbo项目的一部分后来开源。Dubbo通过提供服务通信、负载均衡、容错等框架来简化分布式应用程序的开发，并且支持HTTP/2、REST、gRPC、JsonRPC、Thrift、Hessian2 等几乎所有主流的通信协议以及Dubbo2、Triple (兼容 gRPC) 高性能协议。 以上是 Dubbo 的工作原理图，从抽象架构上分为两层：服务治理抽象控制面 和 Dubbo 数据面 。 Dubbo模块图： 十层模块的作用： Dubbo 服务治理 以下是与Dubbo相关的一些关键特点和概念： 地址发现 Dubbo 服务发现具备高性能、支持大规模集群、服务级元数据配置等优势，默认提供 Nacos、Zookeeper、Consul 等多种注册中心适配，与 Spring Cloud、Kubernetes Service 模型打通，支持自定义扩展。 负载均衡 Dubbo 默认提供加权随机、加权轮询、最少活跃请求数优先、最 ...

高并发系统分布式服务方案服务拆分一体化架构的痛点一体化架构的一些缺陷，这主要体现在以下几个方面： 在技术层面上，数据库连接数可能成为系统的瓶颈： 因为你的系统是按照一体化架构部署的，在部署结构上没有分层，应用服务器直接连接数据库，那么当前端请求量增加，部署的应用服务器扩容，数据库的连接数也会大增。 一体化架构增加了研发的成本抑制了研发效率的提升： 当如此多的小团队共同维护一套代码和一个系统时，在配合的过程中就会出现问题，例如交流、代码冲突等问题。 对于系统的运维也会有很大的影响： 当你的系统扩充到几十万行甚至上百万行代码的时候，一次构建的过程包括编译、单元测试、打包和上传到正式环境，花费的时间可能达到十几分钟，并且任何小的修改，都需要构建整个项目，上线变更的过程非常不灵活。 微服务化例如最开始的社区业务系统，对数据库进行了垂直分库分为用户库、内容库和互动库。但是由于系统是一体化的，每个模块都会直接与数据库相连接。 其实可以把各个模块的逻辑部署成一个单独的服务，这样就可以直接服务之间相互调用。（也可以将公共服务拆分为单独的服务，增加重用性） 服务拆分原则： 做到单一服 ...

消息延迟问题消息延迟监控监控消息的延迟有两种方式： 使用消息队列提供的工具，通过监控消息的堆积来完成； 利用消息队列实现提供的监控工具，例如Kafka中提供的“kafka-consumer-groups.sh 第三方监控工具：JMX 通过生成监控消息的方式来监控消息的延迟情况。 编写并启动一个监控程序，将监控消息定时地循环写入到消息队列中，消息的内容可以是生成消息的时间戳并且也会作为队列的消费者消费数据。 业务处理程序消费到这个消息时直接丢弃掉，而监控程序在消费到这个消息时就可以和这个消息的生成时间做比较，如果时间差达到某一个阈值就可以向我们报警。 减少消息延迟想要减少消息的处理延迟，我们需要在消费端和消息队列两个层面来完成。 消费端 在消费端的目标是提升消费者的消息处理能力： 优化消费代码提升性能： 注意消费线程空转，如果经常发生空转，可以设置固定或者步长递增的等待时间例如10ms~100ms。 增加消费者的数量。 如果想kafka一样一个 Topic（话题）可以配置多个 Partition（分区），一个分区只能由一个消费者消费，则可以让消费者收到了消息之 ...

CDN静态资源加速概述一般在我们的系统中存在着大量的静态资源请求： 对于移动 APP 来说，这些静态资源主要是图片、视频和流媒体信息； 对于 Web 网站来说，则包括了 JavaScript 文件、CSS 文件、静态 HTML 文件等等 一般这些静态资源是部署在Nginx 等 Web 服务器上，由于请求量大常常占据了很高的带宽，这时会出现访问速度慢带宽被占满影响动态请求的问题；所以对于静态资源也需要考虑对其进行访问加速的问题。 所以我们考虑在业务服务器的上层增加一层特殊的缓存，用来承担绝大部分对于静态资源的访问，这一层特殊缓存的节点需要遍布在全国各地，这样可以让用户选择最近的节点访问。这就是CDN。 CDN关键技术CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定。 CDN的关键技术在于两点： 如何将用户的请求映射到 CDN 节点上； 如何根据用户的地理位置信息选择到比较近的节点。 如何让用户的请求到达 CDN 节点 这就需要依靠 DNS 来帮我们解 ...

缓存的读写策略Cache Aside（旁路缓存）策略这个策略数据以数据库中的数据为准，缓存中的数据是按需加载的。它可以分为读策略和写策。 读策略步骤： 从缓存中读取数据； 如果缓存命中，则直接返回数据； 如果缓存不命中，则从数据库中查询数据； 查询到数据后，将数据写入到缓存中，并且返回给用户。 写策略步骤： 更新数据库中的记录； 删除缓存记录（必须在更新数据库后面）。 这样的读写策略能解决大部分并发更新时缓存数据不一致的问题也正说明他不适用于写入频繁的场景，但是还是会出现一种问题 例如：用户数据在缓存中不存在，请求 A 读取数据时从数据库中查询到年龄为 20，在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21，并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存中，造成缓存和数据库数据不一致。 如果你的业务对缓存命中率有严格的要求，那么可以考虑两种解决方案： 一种做法是在更新数据时也更新缓存，只是在更新缓存前先加一个分布式锁解决并发问题。 另一种做法同样也是在更新数据时更新缓存，只是给缓存加一个较短的过期时间。 Read/Wr ...

缓存概述什么是缓存缓存，是一种存储数据的组件，它的作用是让对数据的请求更快地返回。 实际上，凡是位于速度相差较大的两种硬件之间，用于协调两者数据传输速度差异的结构，均可称之为缓存。 例如： 操作系统的快速转换表：TLB（Translation Lookaside Buffer） HTTP的协商缓存 缓存分类静态缓存：这种缓存只能针对静态数据来缓存，一般通过生成静态 HTML 文件来实现静态缓存并在 Nginx 上部署静态缓存可以减少对于后台应用服务器的压力。 分布式缓存：例如Redis、Memcached等就是典型的分布式缓存。性能强劲，并且可以通过分布式方案突破单机限制。 热点本地缓存：热点本地缓存主要部署在应用服务器的代码中（如 HashMap，Guava Cache 或者是 Ehcache 等），因为它们和应用程序部署在同一个进程中，优势是不需要跨网络调度，速度极快，所以用于阻挡热点查询对于分布式缓存节点或者数据库的压力。（但是由于会有多台应用服务器，数据更新无法更新删除缓存，所以有效期很短秒级或者分钟级）

利用NoSQL数据库当系统中某业务的数据已经无法用分库分表来解决的时候，就应该考虑是否需要利用NoSQL数据库来补充传统关系型数据库了。因为它有着天生分布式的能力，能够提供优秀的读写性能，可以很好地补充传统关系型数据库的短板。但是只是互补关系不能完全替代。 提高写入性能数据库系统大多使用的是传统的机械磁盘，对于机械磁盘的访问方式有两种：一种是随机 IO；另一种是顺序 IO。 以 MySQL 的 InnoDB 存储引擎来说，更新 binlog、redolog、undolog 都是在做顺序 IO，而更新 datafile 和索引文件则是在做随机 IO，而为了减少随机 IO 的发生，关系数据库已经做了很多的优化，比如说写入时先写入内存，然后批量刷新到磁盘上，但是随机 IO 还是会发生。 而NoSQL大多是直接写入内存，为了持久化会做顺序IO以日志形式写入磁盘。它们的核心思想就是将随机 IO 变成顺序的 IO，从而提升写入的性能。 场景补充例如商品的搜索场景，如果直接使用传统数据库的模糊查询，性能是根据无法接受的。这个时候就可以使用NoSQL来进行场景补充例如：开源组件 Elasticsear ...