微服务
文章平均质量分 64
WongKyunban
这个作者很懒,什么都没留下…
展开
-
微服务架构下的分布式事务
比如说现在A、B、C三个服务各自使用了不同的数据库,现在有两个请求1和请求2,并发修改同一个数据项,这个数据项分别由这三个服务进行处理,由于网络延迟,这个数据项在三个数据库中的值可能会不一致,如在A中为100,在C中为200.1、A(Atomicity)原子性,在同一组数据库操作中,其中某一步失败了,之前的所有操作都会被回滚,不允许出现部分成功,部分失败的情况。(3)最终一致性:在系统功能正常的前提下,等待足够长的时间之后,某条数据在系统中的状态能够收敛达成一致,之后,读取到的数据都是最新的。原创 2023-12-09 11:21:22 · 100 阅读 · 0 评论 -
kubernetes的服务发现(二)
服务对象中的label selector字段与选择器中定义的标签相匹配的Pod就会纳入当前服务对象的Pod列表中。服务对象的选择控制器会持续扫描和服务对象的标签相匹配的Pod,然后更新到EndPoint对象中。1、调用者向DNS服务发起域名(服务名称)查询,如果本地没有缓存就会被提交到DNS服务,DNS服务返回对应的ClusterIP。ClusterIP是服务对象的IP地址,并不是具体提供服务的Pod的IP地址。服务就是不需要主动去DNS中注册,靠DNS的控制器就能完成服务的自动注册。原创 2023-12-08 21:31:09 · 390 阅读 · 0 评论 -
微服务架构之服务发现
Kubernates的Node节点上都会有一个kube-proxy的代理,这代理会实时检测服务和端口的信息,当有变化时,kube-proxy会在对应的Node节点处修改相当的iptables路由规则,客户端服务就可以比较方便地通过服务名称访问上游服务。典型例子:Eureka这个组件提供了注册中心和客户端,它对服务地址的更新基于发布订阅模式中的拉取方式,也就是说客户端会定时到注册中心拉取最新的数据,这可能会出现服务这此期间进行更新,当时还调用差旧的服务,所以这种技术要求节点与服务的关系相对固定。原创 2023-12-07 23:44:04 · 359 阅读 · 0 评论 -
微服务的应用架构
在这种背景下,无疑单体应用是最合适的,单体应用开发简单,只需要构建一个单独的应用程序,其次,测试也不麻烦,只需要测试端到端的场景和调用接口的测试;当系统壮大后,各方面的复杂度都在增加,就是时候对单体应用的体系进行拆解,典型的手法就是分层。在六边形的边界上有进出的端口,通常以某种协议的API形式出现,与之对应的是外部的适配器,它们将完成外部系统的调用,并通过端口与应用交互。六边形架构的扩展性也非常好,例如我们要引入一种新的通信协议,或一种新型的数据库,那么我们只需要实现对应的适配器就可以完成引入。原创 2023-12-03 20:15:10 · 507 阅读 · 1 评论 -
微服务的流量管理-服务网格
服务网格作为微服务架构中负责网络通信的基础设施,它能够处理网络通信中绝大多数的问题,服务网格通过在每个业务服务前增加一个服务代理,再让这个服务代理劫持流量并转发到业务服务来实现流量管理。服务网格是一个处理服务与服务之间通信的基础设施,负责在云原生应用的复杂的服务拓扑结构下进行可靠的请求传输。服务网络对服务应用是透明的,所有流量管理都由服务代理来完成,服务应用代码一般不需要做修改,服务代理是一个单独的进程(通常以容器的方式部署在业务服务旁和服务应用的容器共享同一个网络环境。,就是从客户端到服务端的流量。原创 2023-12-03 13:29:12 · 472 阅读 · 0 评论