资讯专栏INFORMATION COLUMN

后端架构演进

Flink_China / 2350人阅读

摘要:后端架构演进在公司已经走过很多个年头,有幸能够亲手去创造架构组,甚至带领团队去完成部分架构的调整,验证架构的想法。总结这个架构演进主要是为了解耦业务,释放人力去将业务做得更加精细,提供业务质量。

后端架构演进

在公司已经走过很多个年头,有幸能够亲手去创造架构组,甚至带领团队去完成部分架构的调整,验证架构的想法。希望能够得到大牛们的一些指引。

1.0 时代

传统的 LNMP 架构,杂乱的应用体系,数不清的坑。单体应用的情况下还可以接受,一旦业务发展速度加快,人员不到位,就可能出现这种情况。

这个结构相当简单,数据库在本机,业务代码也在本机,一台机子上有不同的项目。

2.0 时代

虽然说 2.0 时代有了咱们自身的数据库服务器,名义上将数据库与业务代码进行分离,但是服务器还有很多不同的业务代码,还可能相互影响着。

随着时间的推移,这样的结构越来越复杂,每个业务中甚至还穿插着其他业务,维护尤其的累与危险。

3.0 时代

正式提出将业务进行模块化处理,将公共的模块独立成一个基础的组件运行,并由其负责独立处理。

整个过程相关于是将很多业务进行调整,其中涉及的量还不少,并且需要推翻了部分业务的流程,可谓是一个大工程。

自从将业务组件拆分之后,维护起来也相对容易了一些,但是因为拆分了,说明数量增多了,维护的成本也相对较高。

4.0 时代

虽然将组建都拆分了处理啊,但是业务上还是相对杂乱的,于是,我们就重新将业务进行编排,并且加入了网关 + 内部DNS服务器,用来解决端口泛滥的问题。

咱么协议目前还是是用HTTP协议进行通信。

总结

这个架构演进主要是为了解耦业务,释放人力去将业务做得更加精细,提供业务质量。但是解耦意味着人力投入的增加,所以需要适当考虑当前是否适合进行这样的架构调整。

问题:

资源编排: 想要将业务做得更加独立,就需要重新对资源进行编排,独立的业务,独立的资源

服务超时: 拆分之后的业务调用更加复杂,当其中一个链路出现问题的时候,可能会影响整个调用过程出现问题,所以适当的超时处理是必须的。

增加监控的难度: 因为服务多了,调用的关系链更加复杂,需要定位到具体服务器,具体代码,则需要引入调用链监控的环节,目前使用到的是 fiery

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/25587.html

相关文章

  • 架构 - 收藏集 - 掘金

    摘要:浅谈秒杀系统架构设计后端掘金秒杀是电子商务网站常见的一种营销手段。这两个项目白话网站架构演进后端掘金这是白话系列的文章。 浅谈秒杀系统架构设计 - 后端 - 掘金秒杀是电子商务网站常见的一种营销手段。 不要整个系统宕机。 即使系统故障,也不要将错误数据展示出来。 尽量保持公平公正。 实现效果 秒杀开始前,抢购按钮为活动未开始。 秒杀开始时,抢购按钮可以点击下单。 秒杀结束后,按钮按钮变...

    Riddler 评论0 收藏0
  • 从应用到平台 - 云服务架构演进过程

    摘要:应用的研发上线运维运营形成闭环,顺利完成从对内服务到公共平台的升级。从功能角度,只能支持静态方式设置反向代理,然后,而平台有服务对应的后端服务和端口是有动态调整需求。架构上是基础组件需要进行升级,数据访问层日志监控系统等。 介绍        MaxLeap早期是一家研发、运营移动应用和手机游戏公司,发展过程中积累了很多通用组件。这些组件很大程度帮公司在移动研发过程中节省了时间和成本,...

    LiangJ 评论0 收藏0
  • 服务端高并发分布式架构演进之路

    摘要:架构演进单机架构以淘宝作为例子。随着用户数的增长,并发读写数据库成为瓶颈第二次演进引入本地缓存和分布式缓存在同服务器上或同中增加本地缓存,并在外部增加分布式缓存,缓存热门商品信息或热门商品的页面等。 1. 概述 本文以淘宝作为例子,介绍从一百个并发到千万级并发情况下服务端的架构的演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知,文章最后汇总了一些架构...

    FrancisSoung 评论0 收藏0

发表评论

0条评论

Flink_China

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<