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

前言

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

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

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

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的产品,个人认为与扩展脱不了关系。无论在任何的架构设计上,要考虑向前扩展、向后迭代。

可跑路

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

致谢

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

最后修改:1周前 2018-09-04

© 著作权归作者所有

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

云监控入门

云监控是一个对基于云的服务、应用程序与基础架构进行评估、监控与管理的工作。公司利用各种应用程序监控工具来监视基于云的应用程序。下面我们来看看它是如何工作的,以及...

30170
来自专栏IT笔记

给大家推荐8个SpringBoot精选项目

2017年,曾在自己的博客中写下这样一段话:有一种力量无人能抵挡,它永不言败生来倔强。有一种理想照亮了迷茫,在那写满荣耀的地方。

12610
来自专栏云计算D1net

如何管理好企业的数据

灾难恢复没有银弹。一旦发生停机,企业高管们会条件反射地以最快地速度采取各种灾难恢复手段。 虽然大多数IT主管和数据管理专家承认没有万全的安全解决方案来保...

35440
来自专栏Android 开发者

[译] 怎样把取消订阅的用户吸引回来

44040
来自专栏Hongten

不使用 Ruby 的十个理由

请注意:这是一篇主观意识的文章。它的目的并不是要说服你使用或者不使用Ruby,或者其他任何技术。这篇文章所涉及到的环境是 Web 开发,而不是通用的编程。我想...

2.7K10
来自专栏云加头条

电商月将至,腾讯云DCDB助力电商企业应对支付洪峰

第34届中国数据库学术会议(NDBC 2017)已于2017年10月20日至22日在浙江大学举办。本次会议,腾讯云带着其分布式数据库 DCDB(内部代号TDSQ...

25100
来自专栏花叔的专栏

“公众号数据助手”小程序真的出现了

额,老早之前花叔就想做一个公众号管理相关的小程序,然而微信今天就推出了一个类似的小程序,好了,我不用做了。 回归正题,介绍一下这个小程序吧,通过长按以下二维码能...

516110
来自专栏大魏分享(微信公众号:david-share)

从Gartner IT成熟度模型谈Linux运维

前言 本文参考IT基础架构和运维成熟度模型中的技术项,探讨Linux运维相关内容。本文由我和我的另外两名同事一起完成。 从基础架构和IT运维成熟度模型谈起 Ga...

56660
来自专栏云加头条

DCDB让秒杀更从容、购物更狂欢

众所周知,“光棍节”是西方文化席卷中国后的产物。现如今,“光棍节”华丽地演绎了屌丝大逆袭,成为家喻户晓的购物狂欢节。面对巨大的购买流量,电商企业如何应对支付洪峰...

60900
来自专栏沃趣科技

降低保险行业TCO成本最好的方式是……

时至今日,“虚拟化”,“云”等名词早已耳熟能详,其提供的特性:将服务器物理资源抽象成逻辑资源,可以将一台服务器变成几台甚至上百台虚拟服务器;将CPU、内存、磁盘...

16050

扫码关注云+社区

领取腾讯云代金券