前言

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

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

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

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

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

why

为什么要做架构？有一部分人是这样说的
– 做软件就需要架构
– 没架构的软件不靠谱
– 我是架构师这软件我必须做架构
– 我在学习架构，所以我接手的项目要做架构

各位朋友，生活如此多娇，不必互相残害。架构是要做。实际每日的工作中，你一直在架构，感觉到了吗？例如下面的一些日常工作
– 这块的业务响应速度有些慢，我们需要想办法提升速度
– PHP线程经常挂掉，单机配置到极限，我们需要方案去解决
– 数据库经常出现死锁，查看哪块业务造出的并提出解决方案
– 这块的业务耦合太高了。我们开会讨论如何做。

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

设计

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

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

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

物理架构

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

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

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

逻辑架构

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

数据架构

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

代码架构

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

扩展

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

致谢

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

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