什么是架构?
个人所理解的架构的含义应该是：定义一个完整系统中所需的组件以及实现组件间的交互策略。那么很明显，架构设计应该是考虑如何定义和划分好每个组件，然后考虑它们是如何基于不同的交互策略来实现我们业务需要的场景。
什么是组件?
个人认为，只要是隶属于完整系统中的组成部分，都可以看成是组件。这就意味着，架构中不仅要考虑的是我们常见的基础组件，包括应用服务，数据库，网络，物理机等，还有很大的可能需要引入包括缓存，MQ，容器，Nginx等技术组件来支撑业务的完整描述。
什么是框架?
框架可以理解为组件实现的一种规范，比如我们经常说的开源框架，这是可以拿来直接使用的或者在此基础上进行二次开发的，这些应该是关乎代码层面的，规范着组件的具体实现方式。
设计架构的出发点?
对于设计而言，我们首先需要知道，设计的这个架构是做什么的?所以对于我们而言，首先要明确架构的作用是什么?
架构是系统的骨架，通过各个组件的交互链接，支撑起对所有业务的整体抽象描述。所以在个人的理解中，所有架构的出发点都是为业务服务，所以我们的架构设计的一个出发点是 - 业务!
从日PV上千到日PV上亿的业务数量级演变，驱动着单体式系统到分布式系统的架构技术演变，技术不会平白无故的出现和自驱动发展的，都是受到不同的刺激因素的影响进行发展，就好比如果不是人类看到了火，才知道可以取火，那么人类是永远不会平白无故发明火。而我们架构的发展恰好是基于业务的驱动。
什么才是好的架构设计?
上面已经说了，在架构设计过程中当我们系统已经明确了所有的组件，那么剩下的就是考虑的是组件和组件间的交互。
这里的交互不仅仅是理解为基于不同的网络协议通讯，还有比如组件间的缓存如何交互(分布式缓存)，消息队列进行数据交互，是分布式调用还是进程间调用。组件如何能进行良好的交互呢?这就是好的架构设计体现了。
那么好的架构设计是什么呢?
1、能解决当下业务问题
2、能以优雅且可复用的方式解决当下所有业务问题
3、能在未来一段时间都能以第2种方式满足业务
这其实就是健壮的系统体现的特性了，高可用、高性能，安全性、可扩展性、可维护性、可伸缩性，而这恰好是一个架构设计需要考虑的东西。
- 高性能：用户量的保证前提
- 前端优化
- 应用优化
- 数据库优化
- 高可用：保证服务器不宕机
- 数据备份
- 自动发布
- 灰度发布
- 监控报警
- 可扩展：分布式系统，集群
- 负载均衡
- 缓存负载均衡
- 分布式消息
- 服务化
- 安全性：预防网站的各种攻击
- XSS攻击
- SQL注入缓存负载均衡
- CSRF攻击
- 防火墙漏洞
什么是差的架构?
差的架构其实大家都可以显而易见，就是如果大家都抱怨很多地方有牵一发而动全身，那这里的设计肯定有问题，耦合性这些是可以通过很多设计思想和原则来避免的。
我最想提到的是风险这点，是很重要也是很容易被大家忽略的一点，而且是起到指数级作用的。选择的方案再好，如果都是一些掌控不住的技术，那么风险就是无穷大，导致减号右侧无限趋近于0，最终的结果就是收益是负数，投入的成本打水漂，甚至还要加上其它额外的付出。
架构师是做什么的?
架构师应该是基于自己对该行业的理解，对所要设计的系统能够给出总体设计进而进行全局把控的人，并能解决关键问题、指导其他人员落实设计。
好的架构师最重要的并不仅仅是在技术方面的深厚积累，更多的是需要懂得在各种情况权衡各种影响因素之后选择合适的技术实现业务。架构师不会在确定了架构蓝图之后任务就结束了，因为架构不是空中楼阁和水中镜月，架构是要落地的，如果架构师不着手去主导实现自己提出的恢宏蓝图，那这些好看的蓝图能否能稳当落地呢?
在我的个人观察下，市面上比较多公司的架构师可能都比较局限于某些开源框架的应用以及个人的一个技术栈影响而对架构定了型，我碰到过这样的架构师，凭着对技术的狂热，把市面上流行的技术轻易引入项目中，这就会容易引入风险，这是我们所有后续要往技术方面进阶的同学都要注意的地方。
总结
我们需要知道，没有完美的架构，只有合适的架构，架构是需要演变的。在当前的业务驱动下，架构的设计出发点是解决现有需求和问题，那么我们的架构设计就止于此了吗?不是的，虽然我们不提倡过度设计，但是如果作为架构师在这个业务所属的行业中没一点前瞻性的话，其实是不合格的，公司需要的是架构师的技术能力以及经验，从而不会每次当业务进行演变时，导致架构翻天覆地的变化。
