1. 什么是架构？
    架构是一种整体与局部关系的抽象描述，是描述系统要素之间的关系。
  2. 架构公式
    架构 = 要素 + 连接 + 解决问题
    要素：具有特定功能地工具对象
    连接：通过对象地功能、特性、规则关联一起
    问题：即需求、矛盾
  3. 架构类型

业务架构图
技术架构
部署架构
前端架构
后端分层架构

首先明确应用架构的定义，从百度百科上即可了解到何为应用架构：
应用架构（Application Architecture）是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次：

  • 企业级的应用架构：企业层面的应用架构起到了统一规划、承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。在企业架构中，应用架构是最重要和工作量最大的部分，他包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。
  • 单个系统的应用架构：在开发或设计单一IT系统时，设计系统的主要模块和功能点，系统技术实现是从前端展示到业务处理逻辑，到后台数据是如何架构的。这方面的工作一般属于项目组，而不是企业架构的范畴，不过各个系统的架构设计需要遵循企业总体应用架构原则。

简而言之，应用架构图分为两类，一类为多系统应用架构，用来分部署逻辑架构图层次说明不同系统间的业务逻辑关系、信息流、系统边界等等。一类为单系统应用架构，用来分层次说明系统主要组成模块和功能点之间的业务逻辑关系。
从应用架构图的描述方式或岗位角度而言，又分为系统功能性架构图（或叫业务架构图）和系统技术层次架构图（或叫技术架构图）。两者的差异如下：

架构图类型 适用岗位 定位
业务架构图 产品经理 ①帮助产品经理基于对企业业务系统生态有全局掌握的情况下参与制定业务决策。
②帮助产品经理梳理新增系统在企业应用生态中的定位以及和其他系统之间的关系
技术架构图 技术人员 帮助技术人员搭建良好的技术规范和编码大纲

电力相关

上云模式

四种上云模式说明及比对情况，供参考：
来源：《附件二：业务系统容器化上云方案模板.docx》

上云模式 技术组件 存量系统上云适配工作内容
基础架构上云 主要利用云平台的基础设施资源，使用虚拟机、负载均衡、虚拟私有网络、数据库服务、中间件服务等服务。 无需代码改造或者改造量很小（主要涉及存储迁移和数据库迁移改造）。
云平台提供计算、存储、网络资源，系统迁移上云实施方上传程序包，按照传统方式进行安装部署配置。
容器上云 主要利用云平台组件的容器部署能力，使用容器服务、负载均衡、数据库服务、中间件服务等服务。 业务系统需实现本地持久化数据转存，改造工作量较小。
云平台提供容器及K8S服务、容器基础镜像服务，系统迁移上云实施方上传应用包或应用镜像，按照容器部署方式进行安装部署配置。
微服务上云 主要利用云平台的微服务框架，使用容器服务、负载均衡、数据库服务、分布式服务总线及其他中间件等服务。 业务系统应完全基于微服务架构设计、开发、测试、部署；改造工作量非常大。
云平台提供容器及K8S服务、容器基础镜像、分布式服务总线、API网关，应用迁移上云实施方直接上传应用包或应用镜像进行微服务部署。
混合模式上云 业务系统采用混合模式上云，如WEB服务采用容器上云、数据库采用基础架构上云、后台服务采用微服务上云，则业务系统各模块依据其所采取的上云模式决定系统改造工作内容和实施工作量。
类别 虚拟机上云 容器化上云 结论
资源利用 每个虚拟机上都需要安装操作系统，应用运行在操作系统之上。当部署多个应用实例时，每个实例对应一个底层操作系统，造成资源的浪费。 应用直接运行在容器中，多个容器可共享同一个底层操作系统。当部署多个应用实例时，容器可以比虚拟机节省大量的操作系统资源开销。一台虚拟机上可以运行多个容器，通过提升容器密度可以更充分的利用虚拟机
上资源。		 容器部署资源利用率更高
应用交付 应用通常以部署包形式进行交付，通过自动化脚本部署到虚拟机上。也可以将整个应用运行环境制作成虚拟机镜像，虚拟机镜像通常比较大（以GB为单位），发放和拉取一个虚拟机镜像需要分钟级的时间。 应用通常以镜像方式进行交付，容器镜像采用分层叠加机制，比虚拟机镜像更轻量、更标准，具有更好的移植性，发放和拉取一个虚拟机镜像只需要秒级的时间。容器镜像更容易在开发、测试和生产等不同或异构的环境之间流转，结合DevOps技术，可以实现应用的快速迭代和发布。 应用交付
应用调度 实现对应用的动态调度时，是通过编写自动化脚本，逐步命令机器如何一步一步去操作，一旦出现问题就无法执行下去，并且无法自动调整，达不到调度的目标。 容器集群实现对应用的动态调度时，是通过声明式操作设置期望应用达到的实例个数，容器集群对实际运行的容器实例数量进行定时检测和自动控制，当实际数量与期望值不一致时，将自动创建或删除容器实例来维持指定数量，有效的解决了命令式操作异常导致的最终状态不一致问题。当期望值大于实际值时，将触发弹性扩容；当期望值小于实际值时，将触发弹性缩容；当有实例状态不可用时，会立即创建一个新的实例加入集群，保证期望值等于实际值。 应用调度

组件替换

序号 原组件 对应阿里云组件 对应华为云组件
1 Tomcat、Weblogic、JBoss EDASAliTomcat ServiceStage默认提供开源Tomcat
2 Redis、Memcache、Timesten 云数据库Kvstore(兼容Redis及Memcache) 分布式缓存服务DCS（Redis）
3 MongoDB 云数据库MongoDB 文档数据库服务DDS（MongoDB）
4 Kafka、ActiveMQ、RabbitMQ、RocketMQ 消息队列RocketMQ 分布式消息服务（MQS）
5 Atomikos、Bitronix、Fescar 全局事务服务GTS 分布式事务管理DTM
6 SpringCloudGateway、Zuul、Kong 云服务总线CSB API网关APIC
7 Swift 开放存储服务OSS 分布式对象云存储OBS
8 GFS、HDFS 开放存储服务OSS 分布式文件云存储SFS
9 F5负载均衡、Nginx 弹性负载均衡SLB 弹性负载均衡ELB
序号 分类 厂商 组件
1 负载均衡 华为 弹性负载均衡ELB
2 缓存数据库 华为 分布式缓存服务DCS（Redis）
3 消息队列 华为 分布式消息服务（MQS）
4 关系数据库 华为 云数据库 RDS for MySQL
5 对象存储 华为 分布式对象云存储OBS
6 搜索服务 华为 云搜索服务 CSS

网络含义

互联网：正常的
互联网大区：电力外网
管理信息大区：内网
image.png

什么是系统架构、逻辑架构、物理架构、部署结构、功能架构?

系统架构的表现形式通常就是线框图，它的目的是将系统分解成多个独立的子系统，本质上是遵循分而治之的理念。比如一个室内监控系统，它可以包括摄像头、温度传感器、接入网关、管理后台、用户APP等多个子系统，通常当我们采用系统架构这种说法时，被分析的系统往往较为复杂，包含硬件、软件、网络甚至一些外购件；
系统架构应该说也是一种逻辑架构，只是对于很多纯软件项目，通常不是那么个提法，上来直接就是逻辑架构。我过去的经验一般是这样：解决方案层面做系统架构，当分解出某个软件子系统时再对这个软件做逻辑架构设计。比如我们进一步把上述室内监控系统的后台管理软件拆分，那么从逻辑上可以分为用户管理子系统（或者叫模块）、设备管理子系统、告警维护子系统等等。这个由于对软件的逻辑架构而言，通常我们是根据其功能实现来分解的，所以也可以说是功能架构。
部署架构是指你将软件如何部署，这种图的呈现方式没有定论，也可以是UML的部署视图，举例来说你可以将所有的软件模块放在一台WEB服务器上，就打一个war包，也可以用微服务的方式部署在不同的服务器上，当然你的缓存、数据库、文件服务器等都可以独立部署；
从这个角度讲，部署架构其实算是物理架构的一种，也就是说你在逻辑架构上拆分出来的组件（或模块）是如何分解到不同的物理设备上的。为什么说它不等价于物理架构是因为物理架构的概念会更加宽泛，不一定的服务器，比如可能是某个嵌入式硬件；如果针对嵌入式硬件进一步做系统设计分解，那么此时物理架构可能被分解到某一个MCU、DSP甚至是FPGA上；一定要记住，设计是分层的！！
其他会用到的架构，还包括数据架构，这个通常针对纯软件IT系统，通过ER图来表示，可以理解是一种顶层的数据库设计；另外还有运行架构，这个在嵌入式系统里会用到，比如一个嵌入式软件中包括多个并发任务的时候，任务之间彼此如何依赖，调度；
这些工作很难用几句话讲清楚，我也只能以我个人的经验尝试回答下，希望对您有帮助：）