不管是web开发，还是软件开发，架构一直都是一个很热门的话题，

今天也来谈谈自己的一点见解，欢迎拍砖。

一 . 什么是架构。

开发前的选型是架构，

用什么开发语言，用什么框架，前端用什么框架，也是架构

选什么数据库，是关系数据库，还是Nosql，如何做分布式，如何做集群，这些都是架构。

系统如何部署，如何监控是架构

总之，系统中需要考虑的很多很多，都可以称为架构。

1. 首先介绍架构设计三原则：

合适原则，简单原则，演化原则

这几个原则大家基本都知道，也很好理解，但是真正做好，如何做到适度，也是需要权衡的。

一、合适原则

架构设计的几个误区：

1. 最流行架构

微服务很火，是不是立马把用的好好的mvc改成微服务架构？docker很火是不是立马进入容器？

2. 追随一线大厂

我们在做电商，淘宝是一线大厂，要不要直接采用淘宝架构？微信开源了消息队列中间件，我们社交的也直接切换吧？

3. 追求大而全

我们随着业务展开用户量会提升很快，我们要兼容微服务扩展， 要加入消息队列，数据库主从，加入Elasticsearch 有利与后期查询，并且随着系统分布式部署，要加入docker来管理环境，日志管理要上kafka 等等。

以上几点，可以说都是错的，因为我们选型偏离的最主要的矛盾，为我们独特的业务场景，定制合适的系统架构，使用最流行的架构，有没有考虑我们业务特殊性？直接追随大厂有没有考虑我们团队的技术能力和是否真的能碰到大厂那种极端场景？

追求大而全是否让有限的团队资源陷入无穷的低产出工作上？ 架构就是取舍，不求最新，不求最全，只求最合适。

二、简单原则

复杂，就意味着难度增加，不可控风险增加，保持简单，能系统方便理解，方便扩展，耦合度降低。简单并不代表没有技术含量，反而简单的实现更为实用，比花哨设计更能适应系统一步步演化。

虽然复杂的架构显得很牛叉，但是不要为了展示自己的能力而让架构复杂化。否则就是自己挖坑自己跳。

举个例子：

假如我们现在是一个小创业公司，注册用户就 10 万，每天活跃用户就 1 万，每天单表数据量就 1000，然后高峰期每秒钟并发请求最多就 10，我们采用什么样的架构，

天啊，这还要架构，相信很多人都会这样想，这样的系统，一个初级开发就搞得定

一台web server ，一个 MySQL服务器，完全无压力。

特别是很多创业公司初期，人力物力有限，用户也不多，这时候就用最简单的架构，快速的让系统在线上跑起来，把业务做起来才是最重要的。

如果一开始就设计很复杂，花了太多的时间在架构、调试，那么可能很长时间也完不成，商场如战场，机会很容易失去的。

不然，等你搞了分布式，做了集群，缓存、消息队列、微服务，各种服务都做了，发现一两年内根本用不上，反而你的开发和维护成本大大增加了。

三、 演化原则

不管是阿里还是腾讯，他们的系统都不是一天搞这么大的，他们都是经过十几年的积累不断演化的，很多功能也是有过从头重新设计的。所以，不要想着你的系统可以用十年，不然你早就失业了。

所以，在设计一个系统，只能说尽量的考虑系统后面的功能，让系统的伸缩性和扩展性尽可能的好，必要的时候进行重构，生命在于运动，代码在于折腾，我们要敢于重构，善于重构。

如果你的老板告诉你，你们的系统用户量很大，增长很快，一定不要盲目听从，一定要实际调查，当前用户量，数据增长率，再来设计系统，

还是前面的例子，一个简单的系统，一台云服务器，上面部署web server和MySQL，开始足矣。

单台server

半年后，用户量多了，把web server 和db server分别放到两台云主机，这就是 分布式，又可以撑半年了

2台分布式

一年后，系统又有压力了，再增加一台web server和数据server ，做了负载均衡和db的主从、读写分离

集群

再然后，服务化，这时候你的技术团队已经有一定规模。

写在最后：

罗马不是一天建成的。我们要做高内聚低耦合设计，就是为了可扩展。但是我们也要避开过度设计，避免根本不会遇到的场景投入过度资源，设计就是取舍，好钢用在刀刃上，集中资源做主要的事，然后根据未来的方向，

不断重构优化，自然会衍生出最适合本业务的工程。