浅谈架构是为了什么 (下).md · Yume777/Blog

![](https://resources.blog.fastrun.cn/wp-content/uploads/2018/09/2764268624-5b8dfddb8384f_articlex.png)

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

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

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

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

![](https://resources.blog.fastrun.cn/wp-content/uploads/2018/09/2610865816-5b8dfba433e9c_articlex.png)

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

![](https://resources.blog.fastrun.cn/wp-content/uploads/2018/09/2389145605-5b8dfd222c6f3_articlex.png)

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

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

![](https://resources.blog.fastrun.cn/wp-content/uploads/2018/09/2207911866-5b8e1e51cc901_articlex.png)

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

![](https://resources.blog.fastrun.cn/wp-content/uploads/2018/09/4120730968-5b8e1f8e6c97c_articlex.png)

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

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

![](https://resources.blog.fastrun.cn/wp-content/uploads/2018/09/4278400467-5b8e222498254_articlex.png)

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

![](https://resources.blog.fastrun.cn/wp-content/uploads/2018/09/3993613825-5b8e23edee21f_articlex.png)

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

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

![](https://resources.blog.fastrun.cn/wp-content/uploads/2018/09/1507028583-5b8e25cb15646_articlex.png)

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

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

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

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

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

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

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

# 3.*
3.x是一个学习参考，自我反省，自我检讨的过程。参考大厂的架构设计，结合自己公司的架构设计，取其精华、去其糟粕。贴一张大厂的架构图我感觉毫无意义。这里就不多讲了。
# 老一套
现在回到文章的中心思想上。到底为了什么做架构？我的答案是 “活” ，为了让产品活下去而做架构。什么时候可以做架构？ 任意时间都可以做。但要看精力、财力、人力。
## 可扩展
可扩展性上篇文章我说过，是一把束缚我的刀，这把刀是什么？是“灾难”，在设计架构，包括在业务，物理或者是说部署上。这把刀一直在我脖颈处，如果这时为了省事，躲开了，那未来的某个时间，这把刀就会断头。做了五年的程序员。实际困难需求、复杂需求还有部分BUG的产品，个人认为与扩展脱不了关系。无论在任何的架构设计上，要考虑向前扩展、向后迭代。
## 可跑路
做好架构，写好代码。方能轻松跑路，否则后患无穷。

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

Yume777/Blog

简介

发行版

贡献者

近期动态

Yume777/Blog .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

Yume777/Blog