博文精选 | 架构师入门感悟之十

2021-11-16 11:49:29

F5小安

文章速览:

 

行业:互联网

 

关键字:拆分时机、拆分思路、拆分原则、Summary、架构

 

摘要:旧系统拆分时机、拆分思路或原则

 

阅读时长:5分钟

 

 

以下文章来源于InfoQ!作者:莫问

 

 

Summary

旧系统拆分时机

编译、部署困难

对于网站开发工程师而言,打包构建一个巨型应用是一件痛快的事情。或许仅修改了一行代码,执行构建命令后,构建耗时久,好不容易构建完成,发现编译失败,得重新来过。

代码分支管理困难

复用的代码模块有多个团队共同维护修改,代码 merge 的时候总会发生冲突。代码 merge 一般在网站发布的时候,和发布等问题互相纠结,顾此失彼,每次发布都要半夜三更。

数据库连接耗尽

巨型的应用、大量的访问,必然需要将这个应用部署在一个大规模的服务器集群上,应用与数据库的连接通常使用数据库连接池,以每个应用 10 个连接计,一个数百台服务器集群的应用将需要在数据库上创建数千个连接,数据库服务器上,每个连接都会占用一些昂贵的系统资源,以至于数据库缺乏足够的系统资源进行一般的数据操作。

新增业务困难

想要在一个已如乱麻般系统中增加新业务,维护就功能,难度可想而知。

一脚踩进去,发现全是雷,什么都不敢碰。新工程师入职半年,依旧无法接受业务,因为不知水有多深。

于是出现怪现象:熟悉产品的“老人”忙的要死,加班加点干活;不熟悉产品的新人一帮忙就出乱,跟着加班加点;整个项目组热火朝天,加班加点,产品却依旧经常出故障,新功能迟迟无法上线。

旧系统拆分思路或原则

纵向拆分

将一个大应用拆分为多个小应用,如果新增业务较为独立,那么就直接将其设计部署为一个独立的应用系统。

横向拆分

将复用的业务拆分出来,独立部署为微服务,新增业务只需要调用这些微服务即可快速搭建一个应用系统。


微服务框架需求

1、失效转移(FailOver)

对于大型网站的微服务而言,即使是很少访问的简单服务,也需要集群部署,同时微服务框架还需要支持服务提供者的失效转移机制,以实现服务高可用。

2、负载均衡

对于集群部署的服务提供者,服务请求者可以使用加权轮询等手段访问,使服务提供者集群实现负载均衡。

3、高效的远程通信

对于大型网站,核心服务每天的调用次数会达到数以亿计,如果没有高效的远程通信手段,服务调用可能会成为整个系统性能的瓶颈。

4、对应用最少侵入

网站技术是为业务服务的,是否使用微服务需要根据业务发展规划,微服务也需要渐进式的演化,甚至会出现反复,即使用了微服务后又退回到集中式部署,微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署,也可分部署式部署。

5、版本管理

为了应对快速变化的需求,服务版本升级不可避免,如果仅仅是服务实现升级,那么这种升级对服务请求者而言是透明的,无需关注。但是如果服务的访问接口发生变化,就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护,同时升级接口,而网站服务不可能中断,需要服务提供者先升级接口,并同时提供历史版本的服务供请求者调用,当请求者访问接口升级后才可以关闭历史版本服务。

最重要的是需求

Needs---> Values---> Principles--->Practices--->Tools


 

 

以上是针对旧系统拆分的分享,希望对大家有帮助!

 

 

 

阅读原文

 

声明:本文章版权归原作者及原出处所有 。凡本社区注明来源:XXX或转自:XXX”的作品均转载自其它媒体,转载目的在于传递分享更多知识,内容为作者个人观点,仅供参考,并不代表本社区赞同其观点和对其真实性负责。本社区转载的文章,我们已经尽可能的对作者和来源进行了注明,若因故疏忽,造成漏注,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本社区拥有对此声明的最终解释权。

发布评论 加入社群

发布评论

相关文章

博文精选 | TCP 协议灵魂问题,巩固你的网路底层基础

F5小安

2022-01-14 09:11:08 50

博文精选 | 架构师入门感悟之十三

F5小安

2021-11-22 13:19:24 80

博文精选 | 架构入门感悟之十二

F5小安

2021-11-18 17:45:22 93

Login

手机号
验证码
© 2019 F5 Networks, Inc. 版权所有。京ICP备16013763号-1