MINJIEZHOU's Blog

最近比较忙，好久没更新了。这次我们来聊一聊分布式事务。 在微服务体系下，我们的应用被分割成多个服务，每个服务都配置一个数据库。如果我们的服务划分的不够完美，那么为了完成业务会出现非常多的跨库事务。即使按照 DDD 的原则来切分服务还是免不了有的业务场景需要多个业务同时提交成功或者同时回滚的场景。比如会员使用积分下订单这个场景，那么会员服务的积分扣减需要跟订单下单成功同时完成。如果下单成功，但是扣减积分接口失败，那么就会造成数据的不一致性。这个时候我们就需要使用分布式事务来保证数据的一致性。 由于分布式事务要介绍的东西比较多，这一篇只介绍 2PC、3PC 的基本概念，所以 .net 相关的内容大概也只会出现在标题上一次，笑哭。 什么是 2PC 2PC 既 Two-phase Commit ，中文翻译为二阶段提交。2PC 要求每个事务的参与方都把一个事务抽象成2个阶段。下面大概分析下 2PC 事务的流程。 首先提出2个概念： 参与方 分布式事务中所有需要同时进入事务的业务方。 协调器 分布式环境下为了对多个事务参与方进行统一的调度管理，我们需要一个调度器。 [Read More]

最近因为公司的一些原因，我也开始学习一些 JAVA 的知识。虽然我一直是以 .NET 语言为主的程序员，但是我并不排斥任何其它语言。在此并不讨论 JAVA .NET 的好坏，仅仅是对 .NET 跟 JAVA 程序的编译执行过程进行一些简单的介绍跟比较。因为有些内容还是超出自己原来的认知的，所以整理一下做个记录。 .NET .NET 程序的执行过程大概分以下几个步骤： 代码 语言编译器编译 IL JIT 编译 运行 [Read More]

在我们实施微服务之后，服务间的调用变的异常频繁。多个服务之间可能是互相依赖的关系。某个服务出现故障或者是服务间的网络出现故障都会造成服务调用的失败，进而影响到某个业务服务处理失败。某一个服务调用失败轻则造成当前相关业务无法处理；重则可能耗尽资源而拉垮整个应用。为了尽可能的保证我们生产环境的可用性，至少是部分可用性我们就需要一些策略来保护我们的服务。 服务降级 比如我们的订单详情服务里面会调用会员信息服务接口。如果会员信息服务接口故障会造成订单详情服务也同样故障。这时候我们可以对会员信息服务接口进行降级，在发生故障的时候直接返回固定的信息从而保证订单详情主服务是可用的。 另外一种情况是服务器的资源总是有限的，在面对突发的高并发，高流量情况下我们也可以对部分服务进行降级处理，从而释放更多的资源给核心服务，从而保证核心业务正常工作。 熔断 我们的服务很可能是一个链式的调用的过程。期间如果某个服务出现故障，特别是出现超时故障的时候很有可能耗尽服务器的资源从而影响整个服务。比如订单详情服务依赖会员信息服务，如果会员信息服务因为某些原因出现处理过慢、异常等情况，会阻塞整个订单详情服务的链路。而可能其它服务同样依赖订单详情服务，这样其它服务同样也会被阻塞。资源被越来越多的消耗而不释放，造成所有服务处理越来越慢，积压的请求越来越多， 犹如死循环一般，直到所有资源都被耗尽，整个生成环境奔溃。 所以面对这种情况当我们某个服务持续出现故障的时候我们可以直接断开对它的调用依赖，从而保证不会因为请求积压造成资源耗尽的情况发生。 Polly Polly 是一个开源的弹性跟瞬态故障处理类库。它可以在你的程序出现故障，超时，或者返回值达成某种条件的时候进行多种策略处理，比如重试、降级、熔断等等。它是 .NET Foundation 的成员项目。 Policy.Handle< T > Policy.Handle< T > 用来定义异常的类型，表示当执行的方法发生某种异常的时候定义为故障。 当故障发生的时候 Polly 会为我们自动执行某种恢复策略，比如重试。 我们演示项目中，订单接口需要获取会员的详细信息。 http 有一定几率失败，下面我们演示下如果使用 Polly 在出现当请求网络失败的时候进行3次重试。 var memberJson = await Policy.Handle<HttpRequestException>().RetryAsync(3).ExecuteAsync(async () => { using (var httpClient = new HttpClient()) { httpClient.BaseAddress = new Uri($"http://{memberServiceAddress.Address}:{memberServiceAddress.Port}"); var memberResult... [Read More]

上一次我们介绍了Elastic APM组件。这一次我们继续介绍微服务相关组件配置中心的使用方法。本来打算介绍下携程开源的重型配置中心框架 apollo 但是体系实在是太过于庞大，还是让我爱不起来。因为前面我们已经介绍了使用Consul 做为服务注册发现的组件，那么干脆继续使用 Consul 来作为配置中心吧。Consul 除了服务注册发现功能，还有个 Key/Value 存储的功能，我们把本地的 appsettings.json 文件的内容搬到 Key/Value 上就可以实现配置中心了。 把服务的配置迁移至 Consul 让我们来改造一下前面系列文章里的 member_center 项目，把配置文件都迁移到 consul 上面去。 在 consul 控制台点击 “Key/Value” 菜单，点击 “create” 按钮新建一个 Key/Value 对象。 Key/Value 支持按文件夹分类，当我们的 Key 以 / 结尾的时候，consul 会认为这是一个文件夹。 我们在这里输入 “member_center/” 在创建文件夹。 在创建的文件夹目录下继续点击 “create” 按钮。 在 key 文本框里输入 “confing.json” 。 在 Value... [Read More]

上一次我们介绍了Seq日志聚合组件。这次要给大家介绍的是Elastic APM ，一款应用程序性能监控组件。APM 监控围绕对应用、服务、容器的健康监控，对接口的调用链、性能进行监控。在我们实施微服务后，由于复杂的业务逻辑，服务之间的调用会像蜘蛛网一样复杂。有了调用链监控后服务之间的调用可以用图像的方式展示出来，每个请求的性能，响应等都会记录下来。对于提前防范问题，以及排查问题有非常大的意义。 Elastic APM 大家对 ELK 套件一定非常熟悉。ELastic APM 同样也是 Elastic 系列产品的一个组件。Elastic APM 是一款免费开源的应用程序性能监控组件。它底层依赖 Elasticsearch 来存储跟查询数据，使用 Kibana 来展示分析数据。它支持多种程序语音的探针，包括 JAVA，.NET, Nodejs 等语音。对于 .NET 的集成非常方便，只要简单的配置就可以采集 .NET 程序的信息，对代码几乎是零入侵。 Elastic APM 的架构由4个部分组成。 Elasticsearch 负责数据的持久化，查询等能力 Kibana APM数据的分析展示界面 APM Agent 每个服务集成对应的 sdk 后就是一个个 agent，负责采集程序的各种指标数据 APM Server ，agent 采集到数据后会上报给 APM Server ，由APM Server汇集数据后存储到 Elasticsearch 。 [Read More]