并发编程网 - ifeve.com

工作了很多年，架构也做了五六年。今天突然在思考什么是架构，为什么要做架构，架构怎么来做，架构到底是设计的还是演进的？以下就这些思考做一下总结，其中不当之处欢迎不吝赐教。

1.什么是架构？

个人认为架构是服务于商业目标的，商业目标规范了一定的业务需求，性能需求，安全需求，扩展性需求及其他的非功能性需求。在设计架构的过程中，需要根据对应的需求去决定使用什么样的技术，使用什么样的技术需要根据团队现有的技能水平及当前技术发展的阶段去进行取舍。架构就是根据明确的商业目标进行合理的规划，对不同的方案进行抉择，解决问题的过程。

附百度架构定义：

2：为什么要做架构？

凡事预则立不预则废，软件如同一个城市的发展，如果城市没有初期的合理规划，无序发展。工业区与生活区放在一起，生活污水乱排乱放，可想这样的城市谁也不愿意去，也发展不起来。要么推倒重来，要么一蹶不振。所以合理的架构是一个有效的约束及对远景的规划，对软件的开发有指导性作用。

3.架构怎么来做？

在项目的初期阶段，囿于人员，业务及资金上的限制，需要快速的出产品，可能一个普通的三层架构就可以应付绝大部分的需求，不过在初期阶段根据不同的功能划分不同的模块是非常有必要的，对后期项目的垂直拆分，水平扩展有很大的帮助。

随着公司业务的发展，单个项目的复杂度不断增加，人员也在不断的增加，代码量也在不断的新增。任何一个人都无法完全理解所有的业务及代码，新系统的上线时间拖的越来越长，对单个系统的拆分势在必行，基于之前已经有了模块的划分，可以根据不同的业务需求进行模块的组合，形成新的系统。可能这时虽然顶层的系统已经拆分成了不同的系统，各个系统通过lib包的形式进行复用，整个数据的共享还是基于同一个数据库进行，同样就影响了系统的进一步扩展。

用户量增加，单个系统对外服务能力遇到了瓶颈，这时可以考虑水平扩展，服务器负载均衡技术，动静分离，数据库分库分表，热点数据缓存等。

同时公司内部不同的业务系统出现，形成了一个个孤立的烟囱式系统，各个系统间形成了数据孤岛，无法协同。怎样去解决系统之间的互联互通问题。解决方案有很多种：webservice，基于rest的http接口，rpc方案 thrift等，纯的tcp通信方案，MQ等等

面向服务的架构（微服务架构）

虽然临时的远程调用方案解决了系统之间的交互性问题，可是随之而来的问题又不断出现，远程接口之间的调用关系复杂，每次应用的发布都是一个无比困难痛苦的过程。这时可以着手对架构进行大升级了（类似阿里大中台）。微服务架构的出现很好的解决了上述的很多问题，在对架构升级的过程中不能一下子所有的都改了，应该从基础业务，新业务开始，逐渐的剥离。例如用户服务，日志服务等。用户服务为所有服务的基础，首先剥离该业务可以起到示范作用，用户服务业务流程相对简单，剥离容易，同时也可以作为新技术导入期的磨合阶段。另外新起的业务也可以快速的进行试错实验。随着业务的不断发展微服务的治理，服务监控，蓝绿发布，自动化测试，自动化部署等同步的需要提上日程。

4：架构到底是设计的还是演进的？

其实第三个问题已经有了答案。架构一直在变化，且在不断的演进中，不过在项目的每一个阶段需要根据当前所处的环境进行良好的设计，留下充足的扩展空间。在开始时过度的设计可能导致项目的成本工期延误，最终项目失败。

另外想说下：架构是建立在不断的实践中的，只有不断的实践才能知道系统的问题出在哪里。该篇主要还是只停留在了意识形态，后续再用具体的案例来一个个说明吧。