特点,本质

软件架构简介

抽象而言，架构就

　　是对系统中的实体以及实体之间的关系所进行的抽象描述，

　　是对物/信息的功能与形式元素之间的对应情况所做的分配，

　　是对元素之间的关系以及元素同周边环境之间的关系所做的定义；

软件架构的核心价值，即是控制系统的复杂性，将核心业务逻辑和技术细节的分离与解耦；

软件架构是系统的草图，

　　它描述的对象是直接构成系统的抽象组件；

　　各个组件之间的连接则明确和相对细致地描述组件之间的通信。

　　在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现；

架构师的职责是努力训练自己的思维，用它去理解复杂的系统，

　　通过合理的分解和抽象，理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构；

　　能够进行系统分解形成整体架构，能够正确的技术选型，能够制定技术规格说明并有效推动实施落地；

系统复杂性的来源与应对

编程唯一需要的是创造力思维和思维组织能力，这意味着在软件开发过程中最大限制是理解我们正在创建的对象；

Eric Evans 在 Domain‐Driven Design 一书中吐槽了所谓的意大利面式架构，即代码确实做了有用的事，但很难解释它是如何去执行的；他认为造成这种窘境的主要原因是，将领域问题的复杂度与技术细节的复杂度混合在了一起，最终导致整体复杂度的指数级增长；

复杂性的应对永远不会是一劳永逸，我们需要不断地推陈出新，是动态、渐进的重塑自己对软件系统的认识，不断认识问题和寻找更优解的持续迭代。

　　第一个控制复杂性的途径是代码简单，意图清晰（Obvious）。例如: 减少特殊场景的处理，或变量命名一致性都能降低系统复杂性。

　　另一种方式就是对复杂问题的抽象然后分而治之；

理解构架的视角

首先要理清楚架构的视角，因为你所认知的架构和别人所说的架构可能是两码事。对于不同职位的视角是不一样的，

　　比如开发而言他更多的看到的是开发架构；

　　对售前人员，他可能更多的看到的是业务架构；

　　对于运维人员，他看到的可能是运维架构；

　　而对于技术支持和部署人员，他更多的看到的网络和物理架构；

业务架构

核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；

梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；

沟通，方案建议，多次迭代，交付总体架构；

应用/技术架构

技术架构 主要考虑 系统的非功能性特征（对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握）。

功能视角

和业务视角有重合的地方，主要针对开发而言的服务功能；

技术视角

总体

技术框架（technological Framework）是整个或部分技术系统的可重用设计；

从技术层面描述，主要是分层模型，例如持久层、数据层、逻辑层、应用层、表现层等，然后每层使用什么技术框架，

　　例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等，分别说明，要求这些技术能够将整个系统的主要实现概括；

数据架构

基础架构

运维架构

物理架构

物理架构关注软件元件是如何放到硬件上的，专注于基础设施，某种软硬件体系，甚至云平台，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等；

DDD到各种架构

领域驱动设计的战略核心即是将问题域与应用架构相剥离，将业务语义显现化，把原先晦涩难懂的业务算法逻辑，通过领域对象（Domain Object），统一语言（Ubiquitous Language）转化为领域概念清晰的显性化表达出来；

技术架构-分层

采用七层逻辑架构，第一层客户层，第二层前端优化层，第三层应用层，第四层服务层，第五层数据存储层，第六层大数据存储层，第七层大数据处理层。

• 客户层：减少Http请求数，浏览器缓存，启用压缩，Js异步，减少Cookie传输；
• 前端层：DNS负载均衡，CDN本地加速，反向代理服务；
• 应用层：业务拆分；负载均衡，分级管理，应用缓存，服务集群，快速失败，异步调用，服务降级，消息队列，幂等设计等。
• 服务层：提供公用服务，比如用户服务，订单服务，支付服务等；
• 数据层：分布式, 数据库集群，读写分离，NOSQL集群，文件系统集群；分布式缓存；冗余备份（冷，热备[同步，异步]，温备），失效转移（确认，转移，恢复）。CAP理论，一致性算法。
• 大数据存储层：支持应用层和服务层的日志数据收集，关系数据库和NOSQL数据库的结构化和半结构化数据收集；
• 大数据处理层：通过Mapreduce进行离线数据分析或Storm实时数据分析，并将处理后的数据存入关系型数据库。（实际使用中，离线数据和实时数据会按照业务要求进行分类处理，并存入不同的数据库中，供应用层或服务层使用）。

理解架构的服务演化

微服务架构 - Microservices

由 Martin Fowler 在 2014 年提出的，是希望将某个单一的单体应用 转化为多个可以独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合，从而满足业务快速变化及分布式多团队并行开发的需求；