微服务
快乐的码农一枚
这个作者很懒,什么都没留下…
展开
-
dubbo分层
第三层:proxy 层,服务代理层,⽆论是 consumer 还是 provider,dubbo 都会给你⽣成代。第五层:cluster 层,集群层,封装多个服务提供者的路由以及负载均衡,将多个实例组合。第六层:monitor 层,监控层,对 rpc 接⼝的调⽤次数和调⽤时间进⾏监控。第⼆层:config 层,配置层,主要是对 dubbo 进⾏各种配置的。第⼋层:exchange 层,信息交换层,封装请求响应模式,同步转异步。第⼀层:service 层,接⼝层,给服务提供者和消费者来实现的。原创 2023-05-04 14:30:40 · 653 阅读 · 0 评论 -
支付系统架构
支付系统的各种模块,以及难点、痛点原创 2022-10-27 14:41:15 · 279 阅读 · 0 评论 -
web服务需要考虑
域名劫持 改成https 备用域名进行切换 带宽资源耗尽 社交电商每个分享出去的商品图片都有一个唯一的二维码,之前是放在服务端生成二维码图片,访问的话会增加服务端带宽 后面改成客户端自己生成二维码,只是需要从服务端获取很少的json数据即可 ...原创 2020-07-03 11:43:24 · 100 阅读 · 0 评论 -
微服务的一些实践
在核心链路上,服务可以冗余它依赖的服务的数据,依赖的服务故障时,服务尽量做到自保。比如订单服务依赖库存服务。我们可以在订单服务冗余库存数据(注意控制合理的安全库存,防超卖)。下单减库存时,如果库存服务挂了,我们可以直接从订单服务取库存。可以结合熔断一起使用,作为熔断的Fallback(后备)方案 服务之间调用要有熔断、线程隔离的措施 隔离的考虑可以分为 部署的隔离、数据存储的隔离、业务系统的隔离 服务降级 监控 数据库慢查询、服务调用异常、linux系统cpu内存、jvm监测、中间件监测 ...原创 2020-06-18 18:26:10 · 98 阅读 · 0 评论 -
微服务的一些问题
rpc调用服务时,某段时间突然耗时变多 需要设置超时时间,然后降级处理或者熔断 1、重复请求:有可能provider执行完了,但是因为网络抖动consumer认为超时了, 这种情况下重试机制就会导致重复请求,从而带来脏数据问题,因此服务端必须考虑接口的幂等性。 2、降低consumer的负载能力:如果provider并不是临时性的抖动,而是确实存在性能问题, 这样重试多次也是没法成功的...原创 2020-03-24 14:48:58 · 318 阅读 · 1 评论 -
幂等性
查询接口幂等性,已天然支持 删除接口幂等性,已天然支持 修改接口(修改某个值、累加某个数字) 插入接口幂等性 解决办法 前端页面或者app控制短时间重复提交的问题 服务端解决方案 insert使用唯一索引 update使用 乐观锁 version版本法 这种在大数据量和高并发下效率依赖数据库硬件能力,可针对非核心业务 使用select … for update ,这种和...原创 2020-01-09 13:01:00 · 118 阅读 · 0 评论 -
微服务、分布式系统需要考虑的问题
1、限流 hystrix 2、隔离 hystrix 3、熔断 hystrix 4、失败转移 5、数据不一致的情况 采用CP模式 6、redis 每个模块隔离,以免相互影响,搜索的redis影响了订单的redis,避免无法下单 7、db没有分开,导致其他服务用了慢sql,本模块变的很慢,或者直接崩溃 8、失败重试机制、微服务接口的幂等性 9、 分布...原创 2019-12-17 15:23:18 · 334 阅读 · 0 评论