什么是架构和架构本质

针对互联网 网站 来定义架构：
架构是系统的骨架，支撑和链接各个部分，包括组件、连接件、约束规范，以及指导这些内容设计与演化的原理。

组件：类似应用服务 独立模块 数据库 nginx等
连接件：分布式调用 进程间调用 远程调用协议  http tcp 组件之间的交互关系
约束规范： 例如设计原则 编码规范等

系统性地思考，权衡利弊之后在现有资源约束下的“最合理决策”，并由它来指导团队中的每个人，达到思想层面上的一致

架构=组件+交互

架构的本质是对系统进行有序化地重构以符合当前业务的发展，并可以快速扩展。



需要考虑做架构设计的系统

1. 需求相对复杂.
2. 非功能性需求在整个系统占据重要位置.
3. 系统生命周期长,有扩展性需求.
4. 系统基于组件或者集成的需要.
5. 业务流程再造的需要.


架构分类
业务架构 应用架构 技术架构 代码架构 部署架构

业务架构是战略，应用架构是战术，技术架构是装备。
应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。
熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。
如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，需要深入思考的问题。


一 业务架构（俯视架构）：

包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。
一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。
所有问题的前提要搞清楚 业务量有多大，增长走势是什么样，解决高并发的过程，一定是一个循序渐进的过程。 
合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

二 应用架构（剖面架构，也叫逻辑架构图）

硬件到应用的抽象，包括抽象层和编程接口。
应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

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

应用架构2个关键点：

1、职责划分: 明确应用（各个逻辑模块或者子系统）边界

1）逻辑分层
2）子系统、模块定义。
3）关键类。

2、职责之间的协作：

1）接口协议：应用对外输出的接口。
2）协作关系：应用之间的调用关系。

应用分层两种方式：

水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。

垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。

应用间的协作， 应用之间的通讯机制（同步调用/异步消息/共享DB）和 数据格式（文本/XML/JSON/二进制等）

应用架构的本质是通过系统拆分，平衡业务和技术复杂性 

系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。
业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。


三 代码架构（开发架构）

子系统代码架构主要为开发人员提供切实可行的指导  ，统一技术栈或者组件 

代码架构主要定义：

编码规范
配置设计
框架、类库。
项目模块划分
依赖关系


四 技术架构，也叫系统架构

技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。

技术架构主要考虑系统的非功能性特征，系统的高可用、高性能、扩展、安全、伸缩性等


五 部署拓扑架构图（实际物理架构图）

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




架构演进

初始阶段：LAMP,部署在一台服务器
应用服务器和数据服务器分离
使用缓存改善性能
使用集群改善并发
数据库地读写分离
使用反向代理和cdn加速
使用分布式文件和分布式数据库
业务拆分
分布式服务

业务架构是生产力，应用架构是生产关系，技术架构是生产工具。
业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。

企业一开始业务比较简单，比如进销存，此时面向内部用户，提供简单的信息管理系统（MIS），支持数据增删改查即可，单体应用可以满足要求。

随着业务深入，进销存每块业务都变复杂，同时新增客户关系管理，以更好支持营销，业务的深度和广度都增加，这时需要对系统按照业务拆分，变成一个分布式系统。

更进一步，企业转向互联网+战略，拓展在线交易，线上系统和内部系统业务类似，把内部系统的逻辑做服务化改造，同时供线上线下系统使用，变成一个简单的SOA架构。

紧接着业务模式越来越复杂，订单、商品、库存、价格每块玩法都很深入，比如价格区分会员等级，访问渠道（无线还是PC），销售方式（团购还是普通）等，
还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的SOA架构。

同时不管是企业内部用户，还是外部顾客所需要的功能，都由很多细分的应用提供支持，需要提供portal，集成相关应用，为不同用户提供统一视图，顶层变成一个AOA的架构。




衡量架构的合理性

稳定性
高可用 黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率
文档化 不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。
可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。
可复用 
安全




架构模式

分层：横向分层：应用层，服务层，数据层
分割：纵向分割：拆分功能和服务

分布式

分布式应用和服务
分布式静态资源
分布式数据和存储
分布式计算

集群：提高并发和可用性
缓存：优化系统性能

cdn

本地缓存 分布式缓存
异步：降低系统的耦合性
提供系统的可用性
加快响应速度
冗余：冷备和热备，保证系统的可用性
自动化：发布，测试，部署，监控，报警，失效转移，故障恢复

安全：

高性能 
性能测试 前端优化 应用优化 数据库优化
可用性：保证服务器不宕机，一般通过冗余部署备份服务器来完成

负载均衡
数据备份
自动发布
灰度发布
监控报警

伸缩性：建集群，是否快速应对大规模增长的流量，容易添加新的机器
集群
负载均衡
缓存负载均衡
可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化。是否做法开闭原则，系统耦合依赖
分布式消息
服务化

安全性：网站的各种攻击，各种漏洞是否堵住，架构是否可以做到限流作用，防止ddos攻击。

xss攻击  跨站脚本攻击 Cross site scripting 
sql注入
csrf攻击  CSRF 跨站点请求伪造(Cross Site Request Forgery)
web防火墙漏洞
安全漏洞
ssl