前言

架构是一款软件从0到100的演变过程。并非是上来就可以承载什么亿级访问的牛x架构什么的。本篇写给那些想要成为架构师或者正在尝试成为架构师的朋友。

  • 陕西的城墙有架构,阻挡外来攻击
  • 兵马俑黄陵有架构,避免根基倒塌

这是硬性架构,在初期就应考虑清楚其稳定性。

  • 餐厅的人员配置,菜谱的交替更换以及管理的不断完善。

这是软性架构,考虑扩展性。

why

为什么要做架构?有一部分人是这样说的

  • 做软件就需要架构
  • 没架构的软件不靠谱
  • 我是架构师这软件我必须做架构
  • 我在学习架构,所以我接手的项目要做架构

各位朋友,生活如此多娇,不必互相残害。架构是要做。实际每日的工作中,你一直在架构,感觉到了吗?例如下面的一些日常工作

  • 这块的业务响应速度有些慢,我们需要想办法提升速度
  • PHP线程经常挂掉,单机配置到极限,我们需要方案去解决
  • 数据库经常出现死锁,查看哪块业务造出的并提出解决方案
  • 这块的业务耦合太高了。我们开会讨论如何做。

是日常工作中,你无时无刻的在架构,而你与架构师唯一的区别是你是遇到问题再想解决方案,而架构师会提前想好,例如这种方案可以去解决某个问题,但也需要考虑其弊端,弊端出现的方案是什么样的。实际程序员与架构师不分家。

设计

架构设计覆盖一款应用运行的各个方面。包括

  • 物理架构
  • 逻辑架构
  • 数据架构
  • 代码架构

在项目开发初期,没必要将这四个名次想的过于复杂。举个例子

物理架构

作为一个创业公司,公司资金不足,业务也不是太多,数据也不多。那就可以选择

1
阿里云ECS 4M带宽 4G内存 

就完全可以解决实际需求。多整几台服务器做负载、主从完全没必要。

逻辑架构

业务不复杂,将C层,V层,M层分清楚即可。不必要玩什么子系统,例如消息子系统,用户子系统,支付子系统。不仅没帮上什么忙。反而整的自己乱七八糟。很多程序员认为如果在前期不全部设计好,后期很难维护。这其实是一个错误的想法。人无完人,备不住前期设计的还不如后期设计的好呢?

数据架构

在前期数据量不大的时候,完全可以使用单机数据库去存储,玩各种主从,主主你自己不嫌累吗。当然也有例外,对安全特别看重的一系列业务还是需要做主从的。

代码架构

在模块设计上井然有序就可以了。不要出现伪代码,烂代码。

扩展

扩展这个事一直是束缚我“放肆”的一把刀。下篇文章我们会讲这把刀的神秘之处。

致谢

感谢你看到这里,能看到这里你一定是希望提升自己的能力,也希望自己做的每一个项目都能像巨人一样强大。当然我也希望这样。我相信每个程序员都有一个改变世界的梦想。架构并不是一个多么神秘的职业。请等待我下篇文章给朋友们去演示我公司的架构演变。虽然敌不过大厂的架构。但很实用。谢谢

我的博客即将搬运同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=hbjeggsrtt0l