前言
架构是一款软件从0到100的演变过程。并非是上来就可以承载什么亿级访问的牛x架构什么的。本篇写给那些想要成为架构师或者正在尝试成为架构师的朋友。
- 陕西的城墙有架构,阻挡外来攻击
- 兵马俑黄陵有架构,避免根基倒塌
这是硬性架构,在初期就应考虑清楚其稳定性。
- 餐厅的人员配置,菜谱的交替更换以及管理的不断完善。
这是软性架构,考虑扩展性。
why
为什么要做架构?有一部分人是这样说的
- 做软件就需要架构
- 没架构的软件不靠谱
- 我是架构师这软件我必须做架构
- 我在学习架构,所以我接手的项目要做架构
各位朋友,生活如此多娇,不必互相残害。架构是要做。实际每日的工作中,你一直在架构,感觉到了吗?例如下面的一些日常工作
- 这块的业务响应速度有些慢,我们需要想办法提升速度
- PHP线程经常挂掉,单机配置到极限,我们需要方案去解决
- 数据库经常出现死锁,查看哪块业务造出的并提出解决方案
- 这块的业务耦合太高了。我们开会讨论如何做。
是日常工作中,你无时无刻的在架构,而你与架构师唯一的区别是你是遇到问题再想解决方案,而架构师会提前想好,例如这种方案可以去解决某个问题,但也需要考虑其弊端,弊端出现的方案是什么样的。实际程序员与架构师不分家。
设计
架构设计覆盖一款应用运行的各个方面。包括
- 物理架构
- 逻辑架构
- 数据架构
- 代码架构
在项目开发初期,没必要将这四个名次想的过于复杂。举个例子
物理架构
作为一个创业公司,公司资金不足,业务也不是太多,数据也不多。那就可以选择
阿里云ECS 4M带宽 4G内存
就完全可以解决实际需求。多整几台服务器做负载、主从完全没必要。
逻辑架构
业务不复杂,将C层,V层,M层分清楚即可。不必要玩什么子系统,例如消息子系统,用户子系统,支付子系统。不仅没帮上什么忙。反而整的自己乱七八糟。很多程序员认为如果在前期不全部设计好,后期很难维护。这其实是一个错误的想法。人无完人,备不住前期设计的还不如后期设计的好呢?
数据架构
在前期数据量不大的时候,完全可以使用单机数据库去存储,玩各种主从,主主你自己不嫌累吗。当然也有例外,对安全特别看重的一系列业务还是需要做主从的。
代码架构
在模块设计上井然有序就可以了。不要出现伪代码,烂代码。
扩展
扩展这个事一直是束缚我“放肆”的一把刀。下篇文章我们会讲这把刀的神秘之处。
致谢
感谢你看到这里,能看到这里你一定是希望提升自己的能力,也希望自己做的每一个项目都能像巨人一样强大。当然我也希望这样。我相信每个程序员都有一个改变世界的梦想。架构并不是一个多么神秘的职业。请等待我下篇文章给朋友们去演示我公司的架构演变。虽然敌不过大厂的架构。但很实用。谢谢