什么是系统架构
1、什么是架构？
● 提起架构，大家能想到很多，比如房屋架构，组织架构、IT架构，数据库架构，等等，他们都有做一个共同的特点，就是结构和愿景。
● 所以，架构的定义可以概况为：为了达到某个目标（愿景），将产品分解为一系列组件、模块和交互（结构）。
2、架构和设计的区别？
● 关于架构和设计的关系，格雷迪.布奇有一个得到广泛认可的观点：
所有架构都是设计，但并非所有设计都是架构。
● 架构反应了使一个系统成型的重要设计决策，而重要性则是通过改变的成本来衡量。
● 从本质上来说，重要决策即“架构”，其他的都是“设计”。比如说：
- 系统的形态（例如，客户端-服务器、基于web、原生移动客户端、分布式、异步、等等）
- 软件系统的结构（例如：组件、层、交互，等等）
- 技术选择（即编程语言、部署平台，等等）
- 框架选择（例如，Web MVC框架、持久性/ORM框架，等等）
- 设计方法/模式选择（例如，针对性能、可伸缩性、可用性等的方法）
● 架构决策不可能轻易反悔，代价很大。直白的说，不是花费个一天就能改过来的。
● 软件系统架构流程的一个重要部分就是搞清楚哪些是最重要的以及为什么。
3、什么是系统架构？
对软件开发者而言，这里的系统当然特指软件系统。那么系统架构，当然就是指的软件的结构，但是又不仅仅是结构。一方面，系统结构单元主要以软件为基础，包括编程语言和结构、类库、框架、API等技术实现的内容，它由模块、函数、设计模式等加以描述。另一方面，系统架构还关注软件的过程、代码的组织、基础设施建设等项目管理相关的更外延的内容。
著名架构师周爱民老师提出的模型可以更形象的表述这一点，我就直接引用了。
为什么要做架构设计
1、软件开发面临的问题
软件开发中会遇到的问题会很多，其中最重要的有两个：
● 第一个问题：如何提升软件开发效率和效果
这一点涉及的方法很多，比如选择高效的开发工具、流行的框架、选择适合的设计模式等。
● 第二个问题：如何梳理大规模复杂问题的解决方案
对于这个问题，最好的解决方案就是进行 系统架构设计 ，进行问题分解细化。
2、系统架构设计的目的
核心目的当然是解决大规模复杂性。但同时，还有其他一些常见问题，也是我们通过软件系统架构能降低或解决的：
● 对系统的结构没有统一的认识
● 团队里每个人的实现方法和标准不一致
● 个人理解的差异导致的代码质量差异
● 在关键技术框架上存在风险
● 不同角色无法在同一抽象层面交流解决方案的结构
如何做系统架构设计
1、系统架构所处位置
需求分析和 概要设计的内容，它是完成上游设计，进入下游工程的关键衔接，是将用户需求进行抽象再在系统中具象的过程，从而帮助我们进入编码实现的阶段。
2、从需求层面抽象
系统架构设计就是将需求抽象再具象，从而进入实现层面的过程，我们做架构设计的时候，首先要考虑的是从什么角度来理解和抽象，这也被称为架构视图。下面是几种常见的视图：
● 上下文视图
上下文指的是一种环境，通常指的场景。 主要描述系统与环境之间的关系、依赖和交互，包含了各种当前环境数据极其操作，关注于系统的范围和界限。
● 功能视图
功能视图就是从功能出发， 描述系统所需组件定义及各个组件之间的交互关系。包括功能元素、接口、连接器和外部实体。
● 数据视图
数据视图描述系统存储、操作、管理和分发数据的方式，是系统核心业务数据的载体和表现形式。
● 开发视图
开发视图描述软件开发过程，最接近于系统设计的实现方案，包括系统模块的组织、软件复用技术、使用设计、测试的标准化等。
● 部署视图
部署视图描述系统部署环境及系统与其中元素的依赖关系。包含系统部署时所需的运行平台、硬件设备和软件服务等。
● 运维视图
描述系统运行在生产环节时如何进行运维、管理和支持。包括生产环境、运行时的功能/数据迁移、状态/性能监控、配置管理、数据备份还原等。
几个视图和架构设计的主要关系如下：
3、从执行层面分解
从前面我们已经知道，系统架构的本质是 分解。系统拆分的需求来自组织结构变化、交互速度、业务需求及技术需求所引起的变化。一般来说，拆分思路有两种，横向拆分和纵向拆分：
● 纵向拆分。 就是将一个大应用拆分为多个小应用，如果新业务较为独立，那么就将其设计部署为一个独立的应用系统即可。比如电商行业中的商品下单业务就可以拆分成订单、商品和会员等独立业务子系统。纵向拆分关注业务，通过梳理产品线，将内聚度较高的相关业务进行剥离从而形成不同的子系统。
● 横向拆分。 更多关注于技术，通过将可复用的业务拆分出来，独立部署为分布式服务，只需要调用这些分布式服务就可以构建复杂的新业务。其关键就在于识别可复用的业务，设计服务接口，将可复用的业务独立出来部署为服务。横向拆分的核心技术栈就是分布式体系。比如下图就是一个案件研判系统的基本框架。
系统架构是一个复杂的过程，一个系统可能不是简单的纵向横向就能描述，更多的是相互结合。
4、从质量层面评判
如何来评判一个架构设计的好坏，我们称为架构视觉，通常可以从以下几个维度来看 ：
● 安全性。安全性覆盖了从认证授权到数据传输存储中的机密性等所有的事情。
● 性能。就是一个东西有多快，通常指响应时间或延迟。
● 可用性。是软件对服务请求的可操作和可见程度。比如99.9%就是允许每天故障1分钟。
● 可伸缩性。基本就是软件处理多用户、请求、数据、消息等的能力。可伸缩性和并发机制密不可分，因此能在相同时间内处理跟多的东西（比如每秒的请求）
● 可扩展性。可扩展性是比较模糊的，通常我们可以认为是在特定时候可以与其他系统进行对接或增加一些现在不具有的功能，也许是通过插件，也许是API，也许是配置。
