- 业务架构：战略驱动的业务架构设计，需求初期业务的结果和过程描述一般比较模糊，可能来自于某个老板、运营或用户的反馈。客户说海尔洗衣机洗土豆会堵，海尔立马设计专门的土豆洗衣机 业务方向往往是定 方向和结果的叫战略，主要包括业务规划、业务模块和流程以及问题域的列表等。
- 应用架构：业务驱动的应用架构设计，服务复用、跨组协同，简单、灵活、整合是应用架构必须考虑的点，就像你要上线一个聊天功能，那么聊天内容的输入法、文字识别、舆情监控以及视频服务、支付服务等， 它们都是在应用架构分层，下沉淀到平台的产物，在供各个方使用。
- 产品架构：业务提需求，产品定方案，相对于业务的粗放流程，产品架构会更加细腻以及考虑各个模块的分层和边界。
- 数据架构：业务驱动的数据架构设计，数据的获取、数据的存放和数据的使用是数据架构要解决的三个问题，数据库存放、大数据汇总、数据分析等。
- 技术架构：业务和技术趋势双轮驱动的技术架构设计，是离程序员最近的架构设计，它不仅是系统搭建的架构图设计，还包括了结构、功能、流程、逻辑等内容。它的具体描述就是整个系统如何落地的具体实现方案
2. 微服务架构图---技术选型完毕后，接下来就是对于这些技术的运用。这个过程有点像搭积木一样，把每一个区域用适合此位置的积木填充进去。如果是团队初建或者是技术升级，那么这个过程还是比较复杂的，需要大量的验证。不过其实互联网的技术分层和使用已经相对稳定，搭建一个这样的微服务并不会耗费太长的时间
合理划分微服务
微服务架构设计的首要任务就是合理划分微服务，即围绕业务功能创建微服务项目。在划分微服务时，有关微服务粗细粒度的考量，建议在平台创建的初始阶段使用粗粒度的方法，按业务功能进行划分。随着业务的发展及其运营的情况，再依据发展规模考虑是否继续细分。下面，我们将使用水平划分法和垂直划分法两种方法相结合的方式创建微服务。
一方面，在水平方向上，根据业务功能划分微服务，并把这次划分所创建的微服务称为REST API微服务。REST API微服务负责业务功能的行为设计，主要完成数据管理方面的工作，并通过使用REST协议，对外提供接口服务。另一方面，在垂直方向上，再以REST API微服务为基础，实现前后端分离设计，创建Web UI微服务。Web UI微服务不直接访问数据，它只专注于人机交互界面的设计，它的数据存取将通过调用REST API微服务来完成。
这样，经过两次微服务划分，我们就可以创建出REST API和Web UI两种类型的微服务。也就是说，我们只要使用两种类型的微服务，就可以构建一个复杂的业务系统。
使用REST API和Web UI微服务，结合高性能和高并发的设计，再通过微服务的多副本发布，就可以构建一个能适应任何规模访问的、多维的、稳定牢固的网格结构，并且这个网格结构还具有自由伸缩的特性，可以根据业务的发展规模进行扩充或者缩编，这样就可以快速地搭建一个可持续扩展的系统平台。
3. 技术架构图---技术架构图主要是对于研发层面做技术实现指导的，它可以把系统分层和实现结构划分清楚,是离程序员最近的架构设计，它不仅是系统搭建的架构图设计，还包括了结构、功能、流程、逻辑等内容。它的具体描述就是整个系统如何落地的具体实现方案
| 概念架构图都画啥? |
|---|
关键功能，关键质量进，概念架构出，概念架构在系统设计中非常重要，因需求和设计之间存在一道无型的鸿沟，很多人在需求分析后不知道怎么做了。 概念架构是直指系统设计目标的设计思想和重大选择---是关乎任何系统成败的最关健的 指向性的设计。必须同时重视关健功能和关键质量。要明确给出 1 个决定 4 个选型（1 个 决定： 如何划分顶级子系统 , 4 个选型： 架构风格选型 开发技术选型 集成技术选型 二次开发技术选型）
-
概念架构设计要领
-
1 功能架构设计
-
功能设计---功能设计划分顶级子系统,功能设计上一般以模块为类别，由大模块开始不断下放到各个小功能最终组成功能性图表，同时展示了所有功能的从属关系
-
角色设计---每一个系统都会进行角色设计，指的是系统里面有多少角色，一般角色在定义的时候是根据业务需要来制定。以角色定义业务，以业务定义模型
-
资源权限设计(菜单级别的权限设计, 接口权限设计, 数据权限设计)---对于所有后台系统来说，是一个最重要的部分，主要是针对不同人可以访问不同的资源权限，接口权限，数据权限等，从简单到复杂分为7种，以上7种模型的设计主要还是集中在资源权限的设计上，也就是我们最常见的菜单级别的设计，是后面我们要进行接口权限, 数据权限的根基，(接口权限设计的颗粒度是以每个接口中作为资源的颗粒度，这个接口是与每个服务进行挂钩并由超级管理员统一分配给上面的角色或者用户，在进行数据授权的时候统一处理好并返回给用户，这一层的设计上有多种多样，如果存在网关的存在，在进行鉴权的时候一般都放在网关上并结合redis进行鉴权,数据权限设计是每个服务或者每个系统都有自己特定的业务权限数据范围，根据角色获取这些角色可访问的数据范围即可)，备注：接口的鉴权上，可以采用接口注册->接口分配的方式进行，接口注册可以自定义注解进行自动注册或者手动在后台的接口管理上进行手动添加，如果是自动注册的话，一般后台设计上不允许修改，避免影响接口的访问，但是提前约定好规则
- RBAC0模型
- RBAC1模型
- RBAC2模型
- RBAC3模型
- 组织
- 职位
- 含有组织/职位/用户组的模型
-
-
2 用例及活动图设计---活动图是状态图的一种特殊形式
-
用例图设计---用例图是外部用户所能观察到的系统功能的模型图。用例图是系统的蓝图，主要用于对系统、子系统或类的功能行为进行建模，每一个用例图跟产品功能上存在对应关系 用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的 模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模
-
用例活动图设计---用例活动图是从用例图拓展而来，每一个用例图展开后即可变成用例活动图,从两个角度来分析对用例活动图的内容
角度一: 产品经理从用例活动图，获取到的是整体或者个体的业务逻辑。 角度二：研发人员从用例活动图，获取到的是整体或者个体的程序上的业务逻辑 业务用例工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。业务用例由一系列活动组成，它们共同为业务主角生成某些工件。工作流程通常包括一个基本 工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明,工作流程活动图用于研究实现业务目标时所要执行的各项任务或活动的顺序安排。活动既可以是手动执行的 任务，也可以是自动执行的任务。它可完成一个工作单元。活动图是状态图的一种特殊形式。其中所有或多数状态都是活动状态，而且所有或多数转移都在源状态中的活动完成时立即触发
-
-
3 领域架构设计
-
领域图的设计---领域图是从用例活动图演变而来，相对于用例图，它是整个用例的细化展示。领域图是应用程序中的业务逻辑模型，它的每一个对应的方框可大可小，或是子系统、或是服务、或是类库、或是 单个类，实现微服务的本质性可伸缩性、可拓展性, 在以往的设计中，领域架构设计往往并没有出现，从用例开始后整体就开始进入到系统的接口设计，但是微服务的出现导致领域驱动设计开 始流行,对于一个领域模型来说，在面向对象的设计中有个重要的思想就是把事情交给最合适的类去做，这需要不断是联络各个类之间的关系，从语言层面来讲，它具备 5 方面的特性：
1、存在父类，专门用来存储所有子类的公共属性，并且这个类并不是一个值对象。 2、存在实例的字段 3、存在实例的属性 4、存在自己的领域逻辑，具像化来理解就是存在公共的与私有的方法 5、存在自己的领域服务，这个领域服务是静态方法static，并且这个方法可以单独放出来放到特定的服务类中
-
-
- 大型机架构风格（Mainframe）
- 原始分布式架构风格（Distributed）
- Spring Boot 实现单体架构（Monolithic）
- Spring Cloud 实现微服务架构
- Kubernetes 为基础设施的微服务架构
- 后微服务架构风格：云原生时代（Cloud Native）
- AWS Lambda 为基础的无服务架构（Serverless）
- CQRS模式架构
-
6 数据库设计
- E-R图设计
- 表设计
- 数据设计规范
-
7 物理架构设计
- 部署图
- 高可用部署图
- 集群部署图
- 域名
-
8 非功能性设计---系统非功能性设计的7个复杂度
功能需求与质量需求并重---有的放矢，识别复杂度
如何从功能需求向设计过渡： 运用鲁棒图建模技术进行设计
功能性设计的复杂度--功能越来越多，导致系统复杂度指数级上升
解决从功能需求向设计过渡问题就要用到“鲁棒图建模技术”，
-
鲁棒图(Robustness Diagram)---
-
软件系统的鲁棒性(Robustness)---软件“健壮性”， 指当错误发生时，系统依然正确运行功能的能力，从而将程序崩溃的危险减为系统不正常的危险。
如何从质量需求向设计过渡： 运用目标--场景--决策表进行设计
解决从质量需求向设计过渡问题就要用到“场景技术”，其关键是使笼统的非功能目标明确化，
包含5要素：
1. 影响来源
2. 如何影响
3. 受影响对象
4. 问题
5. 所处环境
场景思维的工具
1. 场景卡： 是“关键点”（用于识别场景）
2. 目标--场景--决策表： “纵贯线”（用于打通思维）
概念架构设计要明确的是“1 个决定， 4 个选择”
- 第一步： 通过初步设计，探索架构风格和高层分割
- 第二步： 基于"目标--场景--决策表"思维选择架构风格，划分顶级子系统
- 第三步： 开发技术 集成技术与二次开发技术的选型
概念架构备选方案设计--设计备选方案
-
第四步： 基于“概念架构设计备选方案评审表”对三个备选方案进行评审，敲定概念架构方案
基于已有的技术或架构模式进行组合，然后调整，大部分情况下就能够得到我们需要的方案，但并不意味着架构设计是一件很简单的事情。因为可选的模式有很多，
组合的方案更多，往往一个问题的解决方案有很多个：如果在组合的方案上进行一些创新，那么解决方案会更多。这个阶段也是很多架构师容易犯锚的地方。
第一种常见的错误： 设计最优秀的方案！
很多架构师在设计架构方案时，心里会默认有一种技术情结：我要设计一个优秀的架构，才能体现我的技术能力 正确的做法是：根据架构设计原则中“简单原则”的要求，挑选合适自己业务、团队、技术能力的方案才是好方案；否则要么浪费大量资源开发了无用的系统第二种常见的错误：只做一个方案！
很多架构师在做方案设计时，可能心里会简单地对几个方案进行初步的设想，再简单地判断哪个最好，然后就基于这个判断开始进行详细的架构设计了。 这样做有很多弊端： • 心里评估过于简单，可能没有想得全面，只是因为某一个缺点就把某个方案给否决了，而实际上没有哪个方案是完美的，某个地方有缺点的 方案可能是综合来看最好的方案。 • 架构师再怎么牛，经验知识和技能也有局限，有可能某个评估的标准或经验是不正确的，或者是老的经验不适合新的情况，甚 至有的评估标准是架构师自己原来就理解错了。 • 单一方案设计会出现过度辩护的情况， 即架构评审时，针对方案存在的问题和疑问，架构师会竭尽全力去为自己的设计进行辩护，经验不足的设计人员 可能会强词夺理。 因此，架构师需要设计多个备选方案，但方案的数量可以说是无穷无尽的，架构师也不可能穷举所有方案，那合理的做法应该是什么样的呢？ 正确的做法如下： • 备选方案的数量以3 ～ 5 个为最佳。 少于3 个方案可能是因为思维狭隘，考虑不周全；多于5 个则需要耗费大量的精力和时间，并且方案之间的差别可能不明显。 • 备选方案的差异要比较明显。 例如，主备方案和集群方案差异就很明显，或者同样是主备方案，用ZooKeeper 做主备决策和用Keepal ived 做主备决策的差异也很明显。但是都 用ZooKeeper 做主备决策，一个检测周期是l 分钟， 一个检测周期是5 分钟，这就不是架构上的差异，而是细节上的差异了，不适合做成两个方案。 • 备选方案的技术不要只局限于己经熟悉的技术。 设计架构时，架构师需要将视野放宽，考虑更多可能性。很多架构师或设计师积累了一些成功的经验，出于快速完成任务和降低风险的目的，可能自觉或 不自觉地倾向于使用自己己经熟悉的技术，对于新的技术有一种不放心的感觉。就像那句俗语说的：“如果你手里有一把锤子，那么所有的问题在你看来 都是钉子”。例如，架构师对MySQL 很熟悉，因此不管什么存储都基于MySQL 去设计方案，系统性能不够了，首先考虑的就是MySQL 分库分表，而事实 上也许引入一个Memcache 缓存就能够解决问题。第三种常见的错误：备选方案过于详细。
有的架构师或设计师在写备选方案时，错误地将备边方案等同于最终的方案，每个备选方案都写得很细。这样做的弊端显而易见： • 耗费了大量的时间和精力； • 将注意力集中到细节中，忽略了整体的技术设计，导致备选方案数量不够或差异不大； • 评审的时候其他人会被很多细节给绕进去，评审效果很差。例如，评审的时候针对某个定时器应该是l 分钟还是30 秒， 争论得不可开交。 正确的做法是备选阶段关注的是技术选型，而不是技术细节，技术选型的差异要比较明显。例如，采用ZooKeeper 和Keepalived 两种不同的技术来实现主 备，差异就很大； 而同样都采用Zoo Keeper ， 一个方案的节点设计是／service/node/master ，另一个方案的节点设计是/company/service/master， 这两个方案并无明显差异，无须在备选方案设计阶段作为两个不同的备选方案，至于节点路径究竟如何设计，只要在最终的方案中挑选一个进行细化即可
深思熟虑一一评估和选择备选万案
完成备选方案设计后，如何挑选出最终的方案也是一个很大的挑战，主要原因如下：
• 每个方案都是可行的，如果方案不可行就根本不应该作为备选方案。
• 没有哪个方案是完美的。例如， A 方案有性能的缺点， B 方案有成本的缺点， C 方案有新技术不成熟的风险。
• 评价标准主观性比较强，比如架构师说A 方案比B 方案复杂，但另外一个设计师可能会认为差不多， 架构师也比较难将“ 复杂” 一词进行量化。因此，
方案评审的时候我们经常会遇到几个设计师针对某个方案或某个技术点争论得面红耳赤。
正因为选择备选方案存在这些困难，所以实践中很多设计师或架构师就采取了如下指导思想。
• 最简派
设计师挑选一个看起来最简单的方案。例如，我们要做全文搜索功能，方案l 基于MySQL.方案2 基于Elasticsearch o MySQL 的查询功能比较简单，
而Elasticsearch 的倒排索引设计要复杂得多，写入数据到Elasticsearch 中，要设计Elasticsearch 的索引，要设计Elastic search 的分布
式……全套下来复杂度很高，所以干脆就挑选MySQL 来做吧。
• 最牛派
最牛派的做法和最简派正好相反， 设计师会倾向于挑选技术上看起来最牛的方案。例如，性能最高的、可用性最好的、功能最强大的，或者淘宝用的、
微信开源的、Google 出品的，等等。我们以缓存方案中的Memcache 和Redis 为例，假如我们要挑选一个搭配MySQL 使用的缓存， Memcache 是纯
内存缓存， 支持基于一致性hash 的集群；而Red is 同时支持持久化，支持数据字典，支持主备，支持集群，看起来比Memcache 好很多啊，所以就
选Red i s 好了。
• 最熟派
设计师基于自己的过往经验，挑选自己最熟悉的方案。我们以编程语言为例，假如设计师曾经是一个C＋＋经验丰富的开发人员，现在要设计一个运维管理
系统，由于对Python 或Ruby onRails 不熟悉，因此继续选择C＋＋来做运维管理系统。
• 领导派
领导派就更加聪明了，列出备选方案，设计师自己拿捏不定，然后就让领导来定夺，反正最后方案选对了那是领导厉害，方案选的不对怎么办？那也是
领导“背锅”
正确的选择备选方案做法是：
答案就是“ 360 度环评” ！ 具体的操作方式为： 列出我们需要关注的质量属性点， 然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当
时情况的最优方案。常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。在评估这些质量属性时，需要遵循架构
设计原则l “合适原则”和原则2 “简单原则”，避免贪大求全，基本上某个质量属性能够满足一定时期内业务发展就可以了
假如我们做一个购物网站，现在的TPS 是1000 ，如果我们预期l 年内能够发展到TPS 2000（业务一年翻倍己经是很好的情况了），在评估方案的性能时，
只要能超过2000 的都是合适的方案，而不是说淘宝的网站TPS 是每秒10 万，我们的购物网站就要按照淘宝的标准也实现TPS10 万。有的设计师会有这样的
担心：如果我们运气真的很好，业务直接一年翻了10 倍， TPS 从1000 上升到10000 ，那岂不是按照TPS 2000 做的方案不合适了，又要重新做方案？这种
情况确实有可能存在，但概率很小，如果每次做方案都考虑这种小概率事件，我们的方案会出现过度设计，导致投入浪费。考虑这个问题的时候，需要遵循架构
设计原则3 “演化原则”，避免过度设计、一步到位的想法。按照原则3 的思想，即使真的出现这种情况，那就算是重新做方案，代价也是可以接受的，因为业
务如此迅猛发展，钱和人都不是问题。例如，淘宝和微信的发展历程中，有过多次这样大规模重构系统的经历。通常情况下，如果某个质量属性评估和业务发展
有关系（ 例如，性能、硬件成本等）， 需要评估未来业务发展的规模肘， 一种简单的方式是将当前的业务规模乘以2 ~4 即可，如果现在的基数较低，可以
乘以4 ，如果现在基数较高，可以乘以2 。例如，现在的TPS 是1000 ，则按照TPS 4000 来设计方案：如果现在TPS 是10000 ，则按照TPS 20000 来设计
方案。当然，最理想的情况是设计一个方案，能够简单地扩容就能够跟上业务的发展。例如，我们设计一个方案， TPS 2000 的时候只要2 台机器，
TPS 20000 的时候只需要简单地将机器扩展到20 台即可；但现实往往没那么理想，因为量变会引起质变，具体哪些地方质变，是很难提前太多预判的。举一个
最简单的例子： 一个开发团队5 个人开发了一套系统，能够从TPS 2000 平滑扩容到TPS 20000 ，但是当业务规模真的达到TPS 20000 的时候，团队规模己
经扩大到了20个人，此时系统发生了两个质变：
• 首先是团队规模扩大， 20 个人的团队在同一个系统上开发，开发效率变都很低，系统i是代速度很慢，经常出现某个功能开发完了要等另外的功能开发
完成才能一起测试上线，此时如果要解决问题，就需要将系统拆分为更多子系统。
• 其次是原来单机房的集群设计不满足业务需求了， 需要升级为异地多活的架构。
如果团队一开始就预测到这两个问题，系统架构提前就拆分为多个子系统并且支持异地多活呢？这种“事后诸葛亮”也是不行的，因为最开始的时候团队只有5
个人， 5 个人在有限的时间内要完成后来20 个人才能完成的高性能、异地多活、可扩展的架构，项目时间会遥遥无期，业务很难等待那么长的时间
概念架构设计例子
够，那么架构师就需要提出人员招聘来应对业务发展和技术发展的需要，从而在合适的时机（可能是l 年后，也可能是2 年后）启动“拆分方案”的实施。