浅谈架构是为了什么 (下)

前言

上一章对架构进行了通俗的解释,本章以图文并茂的形式对架构的演变做详细的阐述

架构并非因高并发、大数据而生,以下的架构方式是根据业务演变而变更。

从现在开始,假设我们自己是一个创业的小团队。没资金没人脉,靠技术打天下。现在要开发一套电商系统。开始自己的表演。

1.0

没钱没人,只能买得起一台阿里云学生机。这时我们只能选择使用下面的架构

单机部署整个LNMP环境是唯一选择,这时我们还可以对1.0版本做一些优化的地方,在主从数据库这里,要注意了。单机跑主从简直是多此一举。单机流量本身就有效。主与从的承受是一致的。所以主从在单机跑?(相信你不是在开玩笑),但如果视数据与声明的话,主从还是有必要的(当备份了呗)。优化后的架构图如下

虽然依旧很勉强,但我们将文件存储转移到了其他云,比较少于n个g流量是免费的😄,对php进行了优化,改修改的都改了,主从也做了。这个1.0的版本勉强的撑过了创业初期。然后灾难再一次降临…

1.*

这时候手头已经有点钱了。公司准备再购入一台服务器。这时架构如下所示

新购入的机器与老机做了一个负载均衡,将流量分发。这时候主从数据库就派上了很大的用场。这里先将主数据库作为增删改数据库,而从数据库而是查数据库。接下来可以安逸一段时间了。但在生产环境上,我们需要预知问题,检测bug,所以无奈下又改善架构

将日志,包括mysql慢日志,查询日志,nginx的请求日志,错误日志,php的错误日志,慢日志都暂时存入redis内,至少我存起来了。有问题我能有处可查。随后将大表切分,例如文章表,用户表的。1.x的版本再不断迭代中越来越完善。但一旦出现并发就挂掉。这事看来需要认真的去对待了。

2.0

谈及并发,我了解的并不深入,仅仅知道是一瞬间对服务器的冲击数,解决并发的办法也很简单,将请求分流,分的越细越好(这也并不是越多越好,具体界限,我也不清楚),架构图如下

将用户请求(当然我指的是部分的),例如抢红包,限时抢购等业务,加入到队列中,挂为待处理形态,处理结束后将处理结果存储到redis然后通知用户,定时某个时段将redis数据存储到mysql,结束战斗。我想象的我们的公司已经比较牛x了。购入了很多台服务器。时候对现有的架构做出一些改变了。但并不是天翻地覆的变化。

当然这仅仅是物理架构,真实的业务要复杂一些。接下来通过不断的努力,我们开启了2.x时代。

2.*

应该具备的设备及其环境都准备好了。现在我们需要做的是将业务需求补齐,当然也没有想象的那么夸张。

我们负载均衡作为分发调节器,将请求平均到指定服务器,通过开发语言去查询数据库数据然后返回,这一系列的操作都在监控系统与日志系统的监控中,当然说是系统,实际就是一个后台,一套程序,去监控数据时做筛选。如遇紧急情况则报警。数据正常并不是直接存储到数据库而是扔到队列,任由它翱翔。当业务不断壮大。其缺点或者漏洞并不是某种架构方案可以去解决,要就事论事,瞧病就医。这才是架构师的精髓所在。以上描述的这些套路。不好意思的说已经差不多吸光了我的架构知识库。下面的东西是正在研究的架构。

3.0

我们预计上线的3.0版本引用了服务治理的架构思想。将业务分割,在本地通过tcp直接请求,并非通过http。这块我写过几篇文章,@周梦康 康神也有不错的直播讲解。以下为链接。我就不过多讲解了。

PHP程序员如何简单的开展服务治理架构(一) https://segmentfault.com/a/1190000013481688

PHP程序员如何简单的开展服务治理架构(二) https://segmentfault.com/a/1190000013544601

PHP程序员如何简单的开展服务治理架构(三) https://segmentfault.com/a/1190000013624228

PHP 进阶之路 – 零基础构建自己的服务治理框架(上) https://segmentfault.com/l/1500000011300619

PHP 进阶之路 – 零基础构建自己的服务治理框架(下)https://segmentfault.com/l/1500000011301018

3.*

3.x是一个学习参考,自我反省,自我检讨的过程。参考大厂的架构设计,结合自己公司的架构设计,取其精华、去其糟粕。贴一张大厂的架构图我感觉毫无意义。这里就不多讲了。

老一套

现在回到文章的中心思想上。到底为了什么做架构?我的答案是 “活” ,为了让产品活下去而做架构。什么时候可以做架构? 任意时间都可以做。但要看精力、财力、人力。

可扩展

可扩展性上篇文章我说过,是一把束缚我的刀,这把刀是什么?是“灾难”,在设计架构,包括在业务,物理或者是说部署上。这把刀一直在我脖颈处,如果这时为了省事,躲开了,那未来的某个时间,这把刀就会断头。做了五年的程序员。实际困难需求、复杂需求还有部分BUG的产品,个人认为与扩展脱不了关系。无论在任何的架构设计上,要考虑向前扩展、向后迭代。

可跑路

做好架构,写好代码。方能轻松跑路,否则后患无穷。

致谢

感谢你看到这里,希望本篇可以帮到你。有问题可在评论区留言,谢谢 🙏

最后修改:11个月前
如果觉得我的文章对你有用,请随意赞赏

共有 0 条评论