睿驰
最近在刷leetcode [69. x 的平方根](https://leetcode-cn.com/problems/sqrtx/) 的时候发现 官方给出的 方法三：牛顿迭代 java代码如下： ``` class Solution { public int mySqrt(int x) { if (x == 0) { return 0; } double C = x, x0...
## Spring 监控机制 在学习如何监控 Java 应用之前，我们需要先了解下 SpringBoot 的监控机制。在 Spring 2.x 之前，SpringBoot 使用 Actuator 模块进行监控，而在 Spring 2.x 之后，SpringBoot 使用了 Micrometer 进行监控。 Spring Boot Actuator 模块提供了生产级别的功能，比如健康检查，审计，指标收集，HTTP 跟踪等，帮助我们监控和管理 Spring Boot 应用。这个模块是一个采集应用内部信息暴露给外部的模块，上述的功能都可以通过 HTTP 和...
服务治理的英文单词是SOA governance，维基百科定义 [点此](https://en.wikipedia.org/wiki/SOA_governance) 查看。 所谓“治理”，在汉语词典(简编版)中的解释是“整治、修整”，字面上包含了对被治理对象的问题梳理及改进优化的意思。服务治理是IT治理的一部分，它重点关注服务生命周期的相关要素，包括服务的架构、设计、发布、发现、版本治理、线上监控、线上管控、故障定界定位、安全性等。 在服务的架构体系中，由于服务的提供者和服务的使用者分别运行在不同的进程中（甚至在不同的物理节点上），并由不同的团队开发和维护。团队的协作和服务的协同，都需要进行大量的协调工作。协调工作越多，复杂度越高。任何事物，一旦有了复杂度，伴随着就有了治理的需求，通过治理，为协调工作立规范、打基础、并时时监控，不断优化协调的效率，以期降低复杂度，规避风险，这就是服务治理的由来。 服务的治理既要进行线上的治理，也要进行线下的治理，通过线上线下两大维度进行治理指标的采集，并把它们统一汇总到指标中心，进行综合的汇总、聚合、分析，获得对服务的客观度量。 这些度量指标中，有相当一部分线上的性能及异常指标会被转化为运维事件，一旦触发我们预先设置的阈值，就会更进一步转化成“管控指令”，并通过调度中心下发，进行服务的弹性伸缩、扩容缩容等资源调度操作，或者进行服务的限流、降级、容错、路由调整等管控操作。 另外一部分度量指标，包括架构、开发、测试、运维、过程协作效率等指标会通过治理委员会（泛指，治理成员的集合）进行人为的深入分析，并制定出治理决策，这些治理决策会通过相关的过程优化管理措施进行落地。 这样，通过服务的度量、管控、管理这三大举措，就可以构建起一个三位一体、围绕服务治理的闭环体系。 ### 单体服务（monolithic） 如果服务属于单体结构，服务治理的挑战更多是当单体架构由于承载的业务庞大，服务内部逻辑变得复杂，扩展性也变差。这时候往往不需要特别的服务治理手段，而是将单体服务拆分为微服务，即完成”微服务化“，将原有单体服务架构向微服务架构演进。 ### 微服务（microservices） 业务服务演进到微服务架构后，服务治理问题是否就此终结？远远没有。在微服务架构下，出现了新的服务问题，从而需要对微服务进行服务治理。那微服务又有哪些问题需要治理？ 对于微服务治理，传统的做法都是需要引入微服务研发框架，配合控制平台完成如上服务治理能力的建设。比较常见的微服务研发框架包括SpringCloud、Dubbo等。 对比 SpringCloud、Dubbo 看看他们的共性都有什么，如果把功能相同的进行一下归类，会发现有这样几个主要功能： * 服务注册发现：Eureke，Nacos，Consul，ZooKeeper * 服务配置：Spring Cloud Config，Archaius * 服务熔断：Hystrix，resilience4j * 网关：Zuul，Spring...
常见的负载均衡算法 * WRR (Weighted Round Robin)：权重轮询 * p2c：Power of Two Choices (P2C，两次随机选择) ## P2C 算法介绍 Power of Two Choices (P2C，两次随机选择) 负载均衡算法，主要用于为每个 RPC 请求返回一个 Server 节点以供调用，该算法策略出自论文 [《The Power of Two Random...
> 转载自【芋道源码】全面理解 DNS 及 HTTPDNS：https://mp.weixin.qq.com/s/XvIYa9Ft-0hnCRD3tSmP7Q
> 转载 【酷壳】陈皓 - 与程序员相关的CPU缓存知识：https://coolshell.cn/articles/20793.html
> 《Dynamo：Amazon’s Highly Available Key-Value Store》 英文版：http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf
## 1. 事务基本概念 ### 1.1 什么是事务? 事务是恢复和并发控制的基本单位，事务有四个特性(ACID)： * 原子性(Atomicity)：可以理解为一个事务内的所有操作要么都执行，要么都不执行。 * 一 致性(Consistency)：可以理解为不会存在中间状态的数据，一个事务的执行会使数据从一个一致状态切换到另一个一致的状态； * 隔离性(Isolation)：指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。 * 持久性(Durability)：指的是一个事务提交成功之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。 ## 2 分布式事务 ### 2.1 分布式事务概念 随着互联网高速发展，事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点 之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用。在这种 环境中，我们之前说过数据库的 ACID 四大特性，已经无法满足我们分布式事务。 **分布式事务的最大挑战在于CAP**，在《CAP理论与MongoDB一致性、可用性的一些思考》一文中有详细介绍。简而言之，由于网络分割（P： Network Partition）的存在，用户不得不在一致性（C...
> 分布式事务选型的取舍: https://mp.weixin.qq.com/s/HyWaYIJIqdLp1c_xrrzY1g ## 作者介绍 > 温卫斌，就职于中国民生银行信息科技部，目前负责分布式技术平台设计与研发，主要关注分布式数据相关领域。 微服务兴起的这几年涌现出不少分布式事务框架，比如ByteTCC、TCC-transaction、EasyTransaction以及最近很火爆的Seata。最近刚看了Seata的源码（v0.5.2），借机记录一下自己对分布式事务的一些理解。（3年前这类框架还没成熟，因项目需要自己也写过一个柔性事务框架）。 本文分五部分，首先明确分布式事务概念的演变，然后简单说下为什么大家不用XA，第三部分阐述两阶段提交的“提升”，第四部分介绍Seata的架构的亮点与问题，第五部分谈下分布式事务的取舍。 限于篇幅一些网上可搜索的细节本文不展开阐述（例如XA、Saga、TCC、Seata等原理的的详细介绍）。 ## 一、分布式事务的泛化 提起分布式事务，最早指涉及的是多个资源的数据库事务问题。 wiki对分布式事务的定义： > A distributed transaction is a database transaction in which two or more network hosts are...
> 转自 Saga分布式事务解决方案与实践：https://servicecomb.apache.org/cn/docs/distributed-transactions-saga-implementation/ 传统的单体应用一般采用的是数据库提供的事务一致性，通过数据库提供的提交以及回滚机制来保证相关操作的ACID，这些操作要么同时成功，要么同时失败。各个服务看到数据库中的数据是一致的，同时数据库的操作也是相互隔离的，最后数据也是在数据库中持久存储的。这样的架构不具备横向扩展能力，服务之间的耦合程度也比较高，会存在单点故障。  在微服务架构中， 有一个database per service的模式， 这个模式就是每一个服务一个数据库。 这样可以保证微服务独立开发，独立演进，独立部署， 独立团队。 由于一个应用是由一组相互协作的微服务所组成，在分布式环境下由于各个服务访问的数据是相互分离的， 服务之间不能靠数据库来保证事务一致性。 这就需要在应用层面提供一个协调机制，来保证一组事务执行要么成功，要么失败。 两阶段提交其实比较简单，这边有两个资源提供准备和提交两个接口。 由于隔离性互斥的要求，在事务执行过程中，所有的资源都是被锁定的，这种情况只适合执行时间确定的短事务。 但是为了保证分布式事务的一致性，大都是采用串行化的隔离级别来保证事务一致性，这样会降低系统的吞吐。 但因为2PC的协议成本比较高，又有全局锁的问题，性能会比较差。 现在大家基本上不会采用这种强一致解决方案。 ## ACID与BASE  这里先简单介绍一下酸碱平衡中的酸 ACID。 原子性 事务作为整体来执行，要么全部执行，要么都不执行。一致性 事务应确保数据从一个一致的状态转变为另一个一致的状态。隔离性 多个事务并发执行时，一个事务的执行不应影响其他事务的执行。持久性 已提交的事务修改数据会被持久保持...