没有合适的资源?快使用搜索试试~ 我知道了~
从 0 开始构建一个亿级请求的微服务架构.docx
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 174 浏览量
2022-11-30
12:14:41
上传
评论
收藏 1.42MB DOCX 举报
温馨提示
试读
33页
从 0 开始构建一个亿级请求的微服务架构.docx从 0 开始构建一个亿级请求的微服务架构.docx
资源推荐
资源详情
资源评论
从 0 开始构建一个亿级请求的微服务架构
单体应用因其架构简单、使用技术门槛低、研发快速上手、项目快速上线等
特点是创业公司初级阶段的必然产物。随着平台用户规模的递增,产品功能的丰
富以及需求迭代的频率也会加速,相对应的研发人数也逐步递增,系统的性能问
题、研发人员之间的协作问题、交付速度等一系列的问题就慢慢凸显,这些问题
会逐步演化成阻碍项目推进的“绊脚石”。此时微服务的出现似乎是一根救命稻
草,但凡遇到系统性能、项目交付质量、项目进度等问题的时候就开始准备系统
重构,认为往微服务方向转型就一定能解决这些面临的问题。那么一个在企业在
单体应用架构中到底如何转型微服务呢?在转型之前还需要去了解下实施微服
务的一些前置条件。
本文是根据 在 ArchSummit 全球架构师峰会上的演讲整理 出来的,讲
述了如何从 0 开始构建一个亿级请求的系统的历程, 其中包括了服务拆分、
微服务测试、容量预估以及上线的流程。稳定的系统不仅要依赖好的架构设
计,而且需要对核心代码,高频访问模块精雕细琢,看似不起眼的一些小优
化,长期积累起来就会有质的变化,正所谓细节决定成败,做架构也是同样
的到底。
1
微服务实施的前置条件
很多技术人员在听到企业技术架构要转型,打算从单体架构往微服务架
构转型,得知消息后就异常的兴奋,认为自己马上又能学到新的技术了,开
始去关注到底是选型哪种技术架构, 并运行框架提供的 Demo ,认为成功运
行 Demo 就具备了实施微服务的条件了,等待公司一声令下,就踏上微服
务之旅了。其实这是一种典型的技术人员考虑事情的思维,通过过往的经验
来看,更重要的是在实施微服务之前全员统一思想、 充分培训、 以及工程结
构标准化。
统一思想: 因为在准备实施微服务的时候, 首要条件就是获得高层的认
可,因为涉及到组织结构的调整以及后续人力资源的增补,另外在新架构上
线后难免会出现问题,这个时候需要得到高层的支持。另外,在单体应用中
其组织机构包括开发部、测试部、运维部、 DBA 部,每个部门各司其职由高
层统一指挥,看似很非常合理的组织结构,但是在项目或者迭代实际过程中
会花费大量的时间去跨部门沟通,形成了孤岛式功能团队。
充分培训: 微服务架构的开发人员具备 “精”、“气”、“神”的特质,
否则在后续发展阶段一定会出现各种难题。“精”是指熟悉业务,熟悉选型
的开发框架,而不仅限完成 demo 运行,必须要熟悉原理,最好能熟悉源
码,做到面对问题不慌,“气”是指大家对微服务架构这件事情的思想认知
一致,能够在一个频道上对话,“神”是指需要了解其理论知识,比如什么
是服务治理,什么是服务自治原则,明白为什么需要这样而不是那样。
工程结构标准化: 所有服务交付服务,从代码风格比如类的命名,
module 命名以及启动方式都是一致的, 减少研发人员对于未知的未知而产
生的担心。
在正式开始微服务之前,有必要了解下云原生的 12 要素,它针对微服
务的一些设计思想做了充分的归纳和总结,云原生
12 要素的内容如下:
基准代码:一份基准代码( Codebase ),多份部署( deploy )
依赖:显式声明依赖关系
•
•
•
配置:在环境中存储配置
•
•
•
•
•
•
•
•
•
其中第一条需要特别注意,它要求基准代码或者软件制品只允许有一份,
可以部署到多个环境,不因为环境的改变而需要重新编译或者针对不同的环
境编译多个制品。记住,测试即交付的原则,即你测试的软件制品和交付到
生产的软件制品是一样的。重点强调环境配置和制品库分离,如果是测试环
境的配置,那么软件运行起来就是测试环境,如果是生产环境的配置,那么
软件运行起来就是生产环境。发现很多程序员都喜欢把配置文件写到工程里
面 , 例 如 application-dev.properties 、 application-test.properties 、
application-prod.properties 等 , 然 后 在 系 统 启 动 的 时 候 增 加
spring.profiles.active=dev 来说明环境,其实这种做法是非常的不优雅,
首先违背了云原生 12 要素第一个条件,其次测试环境、生成环境的所有的
配置信息都暴露在代码中,容易导致信息泄露,最后增加运维部署难度,一
旦环境变量标识错误就会导致软件运行失败。
总结为三条:切实需要使用微服务来解决实际问题;组织结构思想
认知一致;前期有完善系统性针对微服务的培训。
2
微服务实施的具体步骤
有些人认为使用 Dubbo 或者 SpringCloud 把系统内部接口调用换
成 RPC 或者 Rest 调用,就完成了微服务改造了,其实这是只是微服务的
冰山一角,完整的去实施微服务必须从全局考虑统一规划, 包括前后端分离,
服务无状态、统一认证以及运维体系的调整等。
前后端分离: 是指前端和后端的代码分离, 前端负责 HTML 页面的编
写以及逻辑跳转,后端负责提供数据接口给前端,前后端开发人员可以并行
开发。前端对跳转逻辑和 UI 交互负责,后端对接口的高可用负责。前端
html 层使用 VUE 框架,node.js 可以起到逻辑跳转的控制, 前后端通信采
用 rest 方式,json 数据格式通信。前后端分离后的好处总结来说包含如下:
各端的专家来对各自的领域进行优化,以满足用户体验优化效果最优
化;
前后端交互界面更加清晰,采用接口方式通信,后端的接口简洁明了,
•
更容易维护;
前端多渠道集成场景更容易扩展,采用统一的数据和模型,可以支撑
•
服务无状态: 是指该服务运行的实例不会在本地存执行有状态的存储,
例如不存储需要持久化的数据,不存储业务上下文信息,并且多个副本对于
同一个请求响应的结果是完全一致的,一般业务逻辑处理都被会定义为无状
态服务。
记得在微服务重构的初级阶段发生过一次特别有代表性的线上故障,有
个研发人员负责验证码登陆模块开发,把验证码存入了本地缓存中,由于我
们开发、测试环境都是单实例部署,所以并没有发现问题,当线上是多实例
部署,所以会导致大量用户登陆失败的场景。这个线上故障的核心问题点在
于没有清楚的认识无状态服务和有状态服务的的使用场景。
剩余32页未读,继续阅读
资源评论
G11176593
- 粉丝: 6668
- 资源: 3万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功