如何用Go支撑海外电商架构演进-易乐天-小米

2017 年 8 月加入小米国际业务研发团队,后续深度参与到多个后端系统性能优化、架构改造。主导国际电商微服务架构演进,并产出基于 gRPC 的微服务框架,以及基于 traefik 的微服务 API 网关,积累了大量微服务架构经验。

2020 年 8 月受邀参加 GIAC 演讲,分享《如何用 Go 支撑海外电商架构演进》。

总的来说,从单体应用演进到微服务架构,主要有以下思路:

1. 垂直拆分。将不同功能拆分到不同微服务,同时区分高频功能和低频功能,合理分配资源。如:将电商中的搜索、商品详情、购物流程、订单、用户中心等功能拆分成独立的微服务。

2. 水平拆分。垂直拆分后,不同的微服务在底层可能有部分逻辑是通过引用公共库的方式来操作底层 redis、数据库等资源。此时如果开辟新的业务线,而新业务线需要启用新的服务,多个业务线都来操作同一份 redis 和数据库的话,容易导致数据不一致的问题,多个业务服务内也会存在重复实现的逻辑。而且后续扩展数据库、redis 数据结构时对各业务影响都较大。此时需要做水平拆分,将公共库的逻辑实现为独立的微服务提供给各业务线调用。也就是做分层设计,将公共逻辑沉淀成共享服务,向大中台、小前台方向演进。

3. 微服务治理。拆分成微服务后,服务间的调用关系变得复杂,排查问题难度也上升,需要引入服务治理手段。比如:服务注册和发现、负载均衡、限流和熔断、链路跟踪、日志和监控等。服务治理包括东西流量治理和南北流量治理。东西流量是指同一层的微服务间互相调用的流量,南北流量是高层应用调用低层服务的流量。东西流量主要靠微服务框架和 ServiceMesh 来治理,南北流量主要靠微服务 API 网关治理。

 

以下是 GIAC 演讲 PPT。

推荐文章

《如何用Go打造千万级流量秒杀系统》

 


                                                                                      扫码关注微信公众号

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
课程背景:如果赶上一个语言火的时候,您想不赚钱都难,android ,苹果,大数据,python我们没有赶上第一批,现在go语言您还想错过吗?现在go语言已经在大公司开始使用,在做服务这块慢慢已经走上热点,现在go语言视频很少而且很基础,我们早已经带着学员开始做实战了。go语言大神班为有一定基础且想深入学习go的学员量身打造,拒绝平庸,与众不同!专技术:对整个大数据生态圈的相关技术都有一定的研究,深入理解Go的原理,熟练使用GO技术解决各种业务需求。通过我们课程中的企业级项目和通俗懂的知道点分析让你更加深了的掌握Go技术!懂架构:对业务有一定的了解,并且可以根据不同的业务场景设计出最优的技术架构。通过我们课程中的企业真实项目,全方位掌握项目的整个开发周期,达到触类旁通的目的!擅调优:一般其他语言开发项目一般都有一定的性能瓶颈,使用GO需要深入掌握项目技术架构特点和技术原理方可对项目中的瓶颈进行调优。通过项目中的调优经验让你掌握该技能!善沟通:GO在项目中扮演一个非常重要的角色,一般是在企业里做服务这块,需要跟各个部门进行协调沟通,所以要具备良好的沟通能力,业务对接能力! 课程研发环境及内容简介:1.课程研发环境项目源代码以Go1.9.2为基准,数据库以mysql为基准,以下环境都适用于项目。开发工具:VScode;数据库工具:mysql  2.内容简介什么是秒杀秒杀场景一般会在电商站举行一些活动或者节假日在12306站上抢票时遇到。对于站中一些稀缺或者特价的产品,电商站一般会在约定的时间对其进行限量销售,因为这些产品的特殊性,会吸引大量用户前来抢购,并且会在约定时间同时在秒杀页面进行抢购。设计思路将请求拦截在系统上游,降低下流压力;秒杀系统特点就是并发量极大,但实际秒杀成功的请求数量确很少,所以如果不在前端拦截可能造成数据库读写锁冲突,甚至导致死锁,最终请求超时,甚至导致系统崩溃充分利用缓存:利用缓存可以极大提高系统读写速度消息队列:消息队列可以削峰,将拦截大量并发的请求,这也是一个异步处理过程,后台业务根据自己的处理能力,从消息队列中主动的拉取请求消息进行业务处理前端方案浏览器端(js):页面静态化:将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素,通过CDN来抗峰值禁止重复提交:用户提交之后按钮置灰,禁止重复提交用户限流:在某一时间内只允许用户提交一次请求,比如可以采取IP限流后端方案服务器控制器层(关层)限制UID(userID)访问频率:我们上面拦截了浏览器的访问请求,但准对某些恶意请求和攻击或者其他插件,在服务器控制层要准对同一个uid,限制访问频率 服务层上面只拦截了一部分请求,当秒杀的用户量非常大时,即使每个用户只有一个请求,到服务层的请求数量还是很大。比如我们有100w用户同时抢购100台手机,服务层并发请求压力至少为100w。1.采用消息队列缓存请求:既然服务器层知道库存只有100台手机,那完全没有必要把100w个请求都传递到数据库里,那么可以先把这些请求都写到消息队列里面缓存一下,数据库层订阅消息减少库存,减库存成功的请求返回秒杀成功,失败的返回秒杀结束2.利用缓存应对读请求:对类似12306等购票业务,是典型的读多写少业务,大部分请求时查询请求,所以可以利用缓存分担数据库压力3.利用缓存对写请求:缓存也是可以应对写请求,比如我们可以把数据库中库存数据迁移到Redis缓存中,所有减库存操作都在Redis中进行,然后通过后台进程把Redis中的用户秒杀请求同步到数据库中数据库层数据库层是最脆弱的一层,一般在应用设计时在上游就需要把请求拦截,数据库层只承担“能力范围内”的访问请求。所以,上面通过在服务层引入的队列和缓存,让底层的数据库高枕无忧

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值