架构概述
https://www.zhihu.com/question/19627054
# 架构是什么？
- 架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架。包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则。并由它来指导团队中的每个人思想层面上的一致。
# 架构师解决什么问题？
架构师需要能够识别定义并确认需求，能够进行系统分解形成整体架构，能够正确地技术选型，能够制定技术规格说明并有效推动实施落地。
架构师不是一个人，他需要建立高效卓越的体系，带领团队去攻城略地，在规定的时间内完成项目。
架构师的职责是了解并关注实际上关系重大但未变得过载的一些关键细节和界面，架构师的角色有：理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构。
# 架构师需要的能力
- 知识储备以及考虑的全面性，从开发、部署、运行、维护态；
- 技术选型能力，极厚的技术功底，开阔的技术视野；
- 在各种约束条件下权衡选择的能力，原则。
# 架构思维
自顶向下构建架构
要点主要如下：
1.首先定义问题，而定义问题中最重要的是定义客户的问题。定义问题，特别是识别出关键问题，关键问题是对客户有体感，能够解决客户痛点，通过一定的数据化来衡量识别出来，关键问题要优先给出解决方案。
2.问题定义务必加入时间维度，把手段/方案和问题定义区分开来。
3.问题定义中，需要对问题进行升层思考后再进行升维思考，从而真正抓到问题的本质，理清和挖掘清楚需求；要善用第一性原理思维进行分析思考问题。
4.问题解决原则：先解决客户的问题（使命），然后才能解决自己的问题（愿景）；务必记住不是强调我们怎么样，而是我们能为客户具体解决什么问题，然后才是我们变成什么，从而怎么样去更好得服务客户。
5.善用多种方法对客户问题进行分析，转换成我们产品或者平台需要提供的能力，比如仓储系统 WMS 可以提供哪些商业能力。
6.对我们的现有的流程和能力模型进行梳理，找到需要提升的地方，升层思考和升维思考真正明确提升部分。
7.定义指标，并能够对指标进行拆解，然后进行数学建模。
8.将抽象出来的能力诉求转换成技术挑战，此步对于技术人员来说相当于找到了靶子，可以进行方案的设计了，需要结合自底向上的架构推导方式。
9.创新可以是业务创新，也可以是产品创新，也可以是技术创新，也可以是运营创新，升层思考、升维思考，使用第一性原理思维、生物学（进化论--进化=变异+选择+隔离、熵增定律、分形和涌现）思维等哲科思维可以帮助我们在业务，产品，技术上发现不同的创新可能。可以说哲科思维是架构师的灵魂思维。
自底向上推导应用架构
对于自底向上的分析方法，如果提炼一下关键词，会得到如下两个关键词：
1.演绎：演绎就是逻辑推导，越是底层的，越需要演绎：
- 从用例到业务模型就属于演绎；
- 从业务模型到系统模型也属于演绎；
- 根据目前的问题，推导出要实施某种稳定性措施，这是也是演绎。
2.归纳：这里的归纳是根据事物的某个维度来进行归类，越是高层的，越需要归纳：
- 问题空间模块划分属于归纳；
- 逻辑架构中有部分也属于归纳；
- 根据一堆稳定性问题，归纳出，事前，事中，事后都需要做对应的操作，是就是根据时间维度来进行归纳。
# 架构框架
TOGAF
TOGAF 是 The Open Group Architecture Framework 的缩写，它由 The Open Group 开发，The Open Group 是一个非盈利的技术行业联盟，它不断更新和重申 TOGAF。
TOGAF 强调商业目标作为架构的驱动力，并提供了一个最佳实践的储藏库，其中包括 TOGAF 架构开发方法（ADM）、TOGAF 架构内容框架、TOGAF 参考模型、架构开发方法（ADM）指引和技术、企业连续统一体和 TOGAF 能力框架。
# **Zachman
# 区分系统、模块、组件、框架和架构
- 系统(system)和子系统：有关联的个体，根据某种规则运行，共同完成独特的功能。子系统：系统的组成部分。
- 模块(module)和组件(component)：模块和组件都是系统的组成部分，只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块，从物理角度拆分得到的是组件。 模块是为了实现职责分离， 组件是为了实现复用。
- 框架：为了实现某个业界标准或完成特定基本任务的软件组件规范，按照规范提供所要求基础功能的软件产品。
- 架构：顶层设计
# 架构原则
计原则有很多，
我们进行架构设计的主导原则是 OCP（开闭原则），
在类和代码的层级上有：SRP（单一职责原则）、LSP（里氏替换原则）、ISP（接口隔离原则）、DIP（依赖反转原则）；
在组件的层级上有：REP（复用、发布等同原则）、CCP（共同闭包原则）、CRP（共同复用原则），
处理组件依赖问题的三原则：无依赖环原则、稳定依赖原则、稳定抽象原则。
# 除了上述设计原则，还有一些重要的指导原则如下：
1.N+1设计：系统中的每个组件都应做到没有单点故障；
2.回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
3.禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
4.监控设计：在设计阶段就要考虑监控的手段，便于有效的排查问题，比如引入traceId、业务身份 Id 便于排查监控问题；
5.多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
6.采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的 bug，出了问题没有很好的商业支持可能会是一个灾难；
7.资源隔离设计：应避免单一业务占用全部资源；
8.架构水平扩展设计：系统只有做到能水平扩展，才能有效避免瓶颈问题；
9.非核心则购买的原则：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
10.使用商用硬件：商用硬件能有效降低硬件故障的机率；
11.快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
12.无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。
架构师知道了职责，具备很好的架构思维，掌握了通用的架构框架和方法论，使用架构原则进行架构设计，不同的业务和系统要求不一样，那么有没有针对不同场景的系统架构设计？下文就针对分布式架构演进、单元化架构、面向服务 SOA 架构、微服务架构、Serverless 架构进行介绍，以便于我们在实际运用中进行参考使用。