架构一，架构是什么

       谈到架构我们首先想到的是架构师，这是很多软件工程师的职业目标。但到底什么是架构，大部分人不能够准确的回答。我们经常会听到微信架构，淘宝架构，还有如层次架构，微服务架构，面向服务的架构，B/S架构，C/S架构，这些我们经常听到，也只知道对方说的是什么，但让你具体描述时，又很难描述清楚。

我们看一下维基百科的定义：软件架构是指系统的一个或者多个结构。这里的结构包括软件构件，构件的外部可见属性以及构件之间的相互关系。

区分一些概念：

系统：一群关联的个体组成，根据规则运作，能完成个体不能单独完成的工作的群体。

模块和组件：不同角度拆分系统，从逻辑角度拆分得到的就是“模块”，从物理角度拆分得到的就是“组件”。登录模块、个人成绩模块；nginx组件，mysql组件。模块更多的表达职责，组件强调可重用，与语言无关，用于组装应用程序。

构件：独立部署的单元，没有外部可见的状态，做为第三方组装的单元。

框架：是组件的规范，提供基础功能的产品。如MVC框架，J2EE框架都是常见的开发规范。

架构设计主要是关注软件构件的结构、属性和交互作用。这里的构件可以是子系统、简单的程序模块或者是面向对象的类，也可以扩充到数据库和能够完成客户与服务器网络配置的“中间件”。

架构就是通过系统性思考，权衡利弊和资源约束下，得到的明确的系统骨架：主要包括子系统，模块，组件以及他们之间的关系，约束规范，指导原则。

从架构分类上看，架构可以是：业务架构，应用架构，技术架构，代码架构，部署架构。可以说这就是使用4+1视图对架构进行描述。

业务架构（统一场景视图）：对系统的业务进行拆分，对领域模型的设计，把现实的业务转化成抽象对象。

京东业务架构图

应用架构（逻辑视图）：也叫逻辑架构图，定义系统有哪些应用，以及应用之间如何分工合作。这里的应用就是构件，各个逻辑模块或子系统作为独立部署的单元，为系统划分了明确的边界。

fabric应用架构

应用架构图关键点：1.划分：明确应用边界，逻辑分层，子系统和模块的定义。2.协作：应用对外的接口协议，应用之间的调用关系。

系统架构就是应用的“分”与“合”。

应用的“分”偏向于业务，反映业务架构，应用的“合”偏向于技术，影响技术架构。“分”降低了业务复杂度，系统更有序，“合”增加了技术复杂度，系统更无序。应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。

应用的“分”可以分为“水平分”和“垂直分”：“水平分（横向）”，按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分；“垂直分（纵向）”，按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。

应用的“合”反映应用之间如何协作，共同完成复杂的业务功能，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。

技术架构（过程视图）：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。

代码架构（实现视图）：也叫开发架构，代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。

主要定义：

1.开发技术选项： 开发语言，开发框架，开发工具

2.模块划分：源码工程；Project目录结构；分包(分库)

3.开发规范：开发/编码规范文档；

部署架构（物理视图）：实际的物理架构图，架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。

物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响。

网络方面：网络拓扑；网络设备；安全机制

性能方面：可靠性、可伸缩性 ，需要什么样设备性能

部署方面：集中式还是分布式；组件部署

---

架构设计与软件生命周期

1.需求分析阶段

在这个阶段对架构的关注几乎为零，在进行需求分析的时候一般不会也不需要去关注软件架构，用句通俗的话说就是，需求还没定架构什么。但是从软件复用的角度看，已有系统的架构模型对新系统的需求工程可以起到很好的借鉴作用，所以如果在这个阶段就关注软件架构，研究架构设计，有助于将软件架构的概念贯穿整个软件生命周期，从而保证软件开发过程的概念完整性，有利于各阶段参与者的交流，也易于维护各阶段的可追踪性。

2.设计阶段

设计阶段是架构设计关注最多的阶段，这一阶段包括：软件架构模型的描述，软件架构模型的设计与分析方法，以及对软件架构设计经验的总结与复用等。

（1）软件架构模型由哪些元素组成，这些元素之间按照何种原则组织。

（2）软件架构模型的多视图表示。从不同的视角描述系统的架构，得到多个视图，将这些视图组织起来以描述整体的架构模型。典型的使用4+1视图模型来描述架构。

3.实现阶段

架构师的职责之一是要交付架构方案，但不是说交付完工作就完成了，为了有效实现从架构设计向实现的转换，架构师还必须保证在架构方案执行过程中，整个开发团队的实施效果与决策保持一致。即使在过程发现了实施与决策的冲突，就又需要重新协调沟通讨论以取得新的一致。如何保证架构设计中的决策在架构执行过程中保持一致，这成为了架构工作的真正难点所在。

软件架构提供了待生成系统的蓝图，根据蓝图实现系统需要较好的开发组织结构和过程管理技术。

（1）研究基于软件架构的开发过程支持，如项目组织结构，配置管理等。

（2）研究从软件架构向实现过度的途径，如模型映射、构件组装、复用中间件平台等。

（3）研究基于软件架构的测试技术。

4.部署阶段

软件架构对部署的研究更多的集中在组织和展示部署阶段的软件架构、评估分析部署方案等方面。

（1）提供高层的架构视图描述部署阶段的软硬件模型。

（2）分析部署方案的质量属性，根据软件架构选择合理的部署方案。

5.维护演化阶段

在这个阶段的软件架构的涉及方面是比较少的。

动态软件架构，如何在设计阶段捕获架构的动态性，并指导软件系统在运行时刻实施这些变化，从而达到系统的在线演化和自适应。现实中软件往往具有动态性，架构会在运行时发生改变。软件架构如何支持这种变化，运行时的变化主要有两种：1.软件内部执行导致的，如客户请求到达时创建新的构件来响应用户，根据不同的配置采用不同的连接子来传送数据。2.软件外部请求对软件进行重配置，如系统升级或修改不能停机，在运行过程中完成对架构的修改。

软件架构重建，从已实现的系统中获取架构的过程。

---

架构设计的重要性

首先架构设计可以降低软件开发的风险，在设计变更相对容易的阶段，考虑架构可能的方案。其次架构设计是降低成本，改进质量，按时和按需交付产品的关键因素。

一个简单的"hello world"程序，你不会去想着做什么架构设计，直接就代码实现了。不过如果让你实现一个双十一秒杀系统时，你还可以直接上来就写代码吗？这时候你就需要进行系统分析，架构设计等一系列工作。随着软件系统规模的增加，系统的组织结构的复杂，会导致了一系列的问题：内部耦合严重，开发效率低；牵一发动全身，后续修改和扩展困难；系统逻辑复杂，容易出问题，排查修复困难。

架构设计的主要目的就是为了解决复杂度带来的问题。理解每个架构背后所需要解决的复杂点，对比自己的业务复杂点，可以参考复杂点相似的方案。