一张图引发的深思：你了解过架构设计体系吗？熬夜整理这份文章 _架构设计

无意中在浏览文章的时候，发现了这样的一张图

文章插图

没什么大不了的，就是一个网站的系统架构设计，很简单，一目了然，但是可能小编比较能瞎想呀，由此联想到很多东西，比如架构设计体系
大家有没有考虑过达到企业规模的软件系统该如何设计呢（已经是这个层次的大佬，膜拜）？在开始写代码之前，我们需要选择一个合适的架构，这个架构将决定软件实施过程中的功能属性和质量属性。因此，了解软件设计中的不同架构模式对我们的软件设计会有较大的帮助。

文章插图

但是，在进行这个话题之前，基础的东西我们应该知道呀，往下看
什么是架构和架构本质在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。
我们主要针对互联网服server系统（类似网站）来定义架构：架构是系统的骨架，支撑和链接各个部分，包括组件、连接件、约束规范，以及指导这些内容设计与演化的原理。
组件：类似应用服务，独立模块、数据库、Nginx等等、
连接件：分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系、
约束规范：定规则做限制：例如设计原则、编码规范等等。
是系统性的思考，权衡利弊之后在现有资源约束下的“最合理决策”，并有它来指导团队中的每个人思想层面上的一致。
即架构=组件+交互。
这类似建筑设计规划，城市总体规划等，其实就是架构，只是应用的场景不同。盖一座小房子，可以拍脑袋干起来，但是当你要盖一座大楼，如果没有一个建筑设计规划，可以想象搭理最后是什么样？
架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。
那什么样的系统要考虑做架构设计?
1. 需求相对复杂.
2. 非功能性需求在整个系统占据重要位置.
3. 系统生命周期长,有扩展性需求.
4.系统基于组件或者集成的需要.
5.业务流程再造的需要.
2、架构分类
架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.

文章插图

业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。
熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。
如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。
一、业务架构（俯视架构）：
包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。
没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。
所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。
看看京东业务架构（网上分享图）：

文章插图

二、应用架构（剖面架构，也叫逻辑架构图）：
硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。
类似：

文章插图

应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。
应用架构图关键有2点：
1、职责划分: 明确应用（各个逻辑模块或者子系统）边界