聊聊应用系统架构的0到1

默默在看新机会的你，是不是面试的时候，偶尔被问起“能不能简单介绍一下项目的应用系统架构”？

沉迷于业务开发的你们，有没有考虑过“用户访问到你开发的业务功能，到底经过了哪些环节”？

 

今天我将结合这些年的一些认知理解，开坛设法给大家讲一讲应用系统架构的从 0 到 1。

 

01.  如何造一个大泥球？

 

产品汪：紧急需求，2 天时间完成 x 网站的上线，包含知识问答页面功能。

 

程序猿：时间短，任务紧。一切以上线为目标，那一切皆可是静态，一切皆是硬编码。花半天时间，让前端妹子写成静态 html，打成 x.war 包，放到web服务器（tomcat）就轻松搞定所有。

 

 

产品汪：上一版的需求功能实现不错，领导很满意。接下来要实现注册、登录功能。其中注册功能包含开通三方账户，开通三方账户会存在超时现象，超时后需要继续开通账户，前端页面提示开户处理中。

 

程序猿：注册成功需要用 mysql 做存储；开通三方账户超时的需要继续处理，那这个只能加个定时任务系统来重新跑批支持了。

 

 

产品汪：没想到你们开发团队挺给力啊，上期的功能又得到了领导的大力认可，不过我们想看看开通失败的用户有哪些，顺带着能修改部分信息？另外我们还想通过页面添加知识问答的文章？

 

程序猿：没问题，产品汪只要需求，我们猿就开撸。不就是再开发个运营管理平台么，代码copy、粘贴，so easy！！

 

 

到此一个小而全的大泥球系统就产生了，或许你已经从事了 n 年的研发，也一直不停的再和这几个系统打交道。

 

02. 如何使大泥球跑的更好？

 

起初产品需求简单，开发的功能也简单，网站系统架构也简单。如上图所示：网站架构用一台web服务器就轻松搞定。

 

 

随着业务推广，如上图所示：用户量逐日增长，单台web服务器（tomcat）肯定不能满足网站的需求。

 

 

面对这个问题，不得不提提尼古拉斯赵四说过的一句话：世界上没有什么事，是一顿烧烤不能解决的，如果有，那就两顿。这个问题不就是这种解决方案么，一台 web 服务器不够，那就再加一台呗。但是用户却郁闷了，访问地址变成了两个，这用户、产品汪们肯定都不能接受。

 

 

程序猿再三思考一二。如上图所示：那就站在尼古拉斯赵四的肩膀上，再部署一个nginx专门用来做分发，那问题不就解决了么。web 应用服务器部署的问题是解决了，但是却引入了另外一个问题，如果做分发的nginx挂了，咋办呢？

 

 

各位看官肯定也想到了尼古拉斯赵四的解决方案：那就再部署一份 nginx。但是用户也会很郁闷，访问地址又变成了两个，这用户、产品汪们肯定都不能接受。

 

 

程序猿往往会出其不意、未雨绸缪。天上飘来五个字“那都不是事”，加个 lvs 支撑一下问题不就迎刃而解啦。结合前面的步骤，你肯定也会有疑问“如果 lvs 挂了怎么办？”，若有此疑问，说明你的思考没毛病。如上图所示：lvs 是主备，并且主备之间进行通讯，如果 master 主的挂掉，备的会成为主节点继续对外服务。

 

到目前为止你对应用架构集群的部署就了解差不多了，随着业务的逐日增多，其中nginx集群可以横向扩展、web服务器也是可以横向扩展，但是 mysql 数据库势必会成为瓶颈，那该怎么办呢？

 

 

如上图所示：面对mysql成为瓶颈时，想到的便是分工明确、各司其职、进行数据库读写分离。一般也会引入基于内存的数据库 redis，把经常读的信息缓存一份。

 

如果数据量级特别大，那不得不用一下数据库分库分表，可用的技术有 mycat、sharding-jdbc，今天就不再进行深入展开啦。

 

03. 带你装 b，带你飞

 

另外在微服务发展盛行的今天，上述的应用架构（单体架构）确实也存在有不足点，就送给大家一张图，大家自己搜一下微服务相关的知识，脑补一下空白吧。

 

 

再送给大家抛一个“service mesh”服务网格的概念，有时间也可以稍微了解一下，技多不压身。

 

 

04. 写在最后

 

今天主要结合个人的理解，简单聊了聊应用架构的部署演变历程，希望你能够有所收获。好了，码字不易，画图更不容易。如果感觉稍微有点意思，多多关注「一猿小讲」。