企业传统IT架构微服务转型-售前方案制作思考

传统 企业 IT 架构 的问题

系统 是建设 的最小单位，那么 这里 的业务系统 实际 就是 我们 说的单体 应用 ，讲问题 实际上 更多 是讲传统 单体 应用 存在的问题 有哪些 ？ 

如果 从整体 生命周期 来看 ，实际上 是可以 从规划 选型 期，开发 建设期 ，运维 期几个 方面 来谈。 

本身 里面 又包括 了软件工程 ，项目管理 ，过程 支撑 三个 维度 的内容 。

规划 选型 期更多 选择 是厂商 比较 产品化 的产品 ，你很难 去定一套 技术架构，开发 标准 和规范 体系 ，这也是后续 导致 整体 IT 架构 里面 多语言 ，多数据库 ，多开发框架，多接口类型 的一个 主要 原因 。

对于 开发 建设期 ，实际上 最主要 的问题 还是 整个 业务系统 里面 各个 模块 间紧耦合 ，无法 拆分 ，其次 就是 大量 共性 的内容 重复 建设 的问题 。 

这里 可以 画图 描述 ，如何把 各个 业务系统 共性 内容 统一 掉，并下沉 到平台 统一 建设 ，构建 平台 +应用 ，应用层 通过 微服务 模块 构建 思路 来完全 松耦合。

在开发 建设期 ，实际上 还需要 谈一个 重要 问题 ，就是 传统 建设 模式 下响应 变化 的能力 弱，都是 业务 需求 和功能 ，前端 和后台 逻辑 完全 绑定 死的。 

而实际上 引入 SOA思路 和微服务架构 化后 ，应用 构建 逻辑 发生了变换 ，即核心 的SOA思路 ，即先搭建 中台 （技术中台+业务中台），然后 暴露 中台 关键 能力 和服务 ，再由这些 服务 来组装 上层 的关键 前端 业务 和流程 。

对于 标准规范 体系 ，实际上 仍然 是包括 三个 方面 的内容 ，项目管理 类，软件工程 类，过程 支撑 类，再加上 后续 运维 期的的话 还包括 IT 治理 和服务治理类。 

本身 这些 规范 如何 和敏捷 方法论 ，DevOps和持续集成 等融合 。 

规范 作用 一个是使过程 标准化 ，模板 化，其次 是加强 甲方 对整个 项目 的管控 力度 。

对于 问题 和现状 的新思考

传统 IT 架构 的问题 作为 PPT 方案 的引入 是合适 的，但是 不适合 谈得太复杂 ，在我最早 编写 企业私有云 PaaS平台建设 方案 的时候 整理 过一页 简单 PPT 可参考 。

简单 来讲 ，传统 IT 架构 的问题 只需要 谈两个点。

其一 是应用 本身 的高可用 和扩展性出现 问题

其二 是应用 对业务 敏捷性 的响应 无法满足

这两点 刚好 是微服务架构 优点 可以 很好 去解决 的点。

微服务架构 概述

传统 IT 架构 的问题 ，最终 通过 微服务架构 建设 来解决 。 

那么 问题 和解决方案 直接 就有一个 匹配 和映射 的过程 。

对于 PPT 方案 的陈述 可以 采用 两种 方式 。

方式 一是 先从传统 IT 架构 的问题 引出 ，原来 的单体 应用 需要 进行 组件化 拆分 ，以提升 应用 本身 的横向 扩展 能力 ，其次 是各个 组件 应该 暴露 轻量 可复用 的API 接口 ，

上层 应用 可以 基于 API 接口 进行 复用 和组装 编排 。 

技术 建模 和建设 实施 全生命周期 的完整 方法论 。

也就是在微服务架构 概述 完成 后给出 一个 整体 的微服务架构 建设 方法论 。 

这个 方法论 里面 有三个 重要 阶段 ，如下 ：

微服务架构 规划 和咨询

微服务 开发环境 选择 和微服务 开发 交付

微服务 管控 治理

那么 后续 的PPT 就应该 在微服务 这三大部分 内容 展开 进行 详细介绍 。

微服务架构 -咨询 和规划

咨询 规划 做什么事情？

首先 应该是调研 清楚 当前 企业 的IT 架构 是如何 的？ 

当前 的架构 下存在 什么问题？ 

然后 是给出 企业 本身 的微服务架构 转型 思路 ，具体 的微服务架构 演进 路线 。

在演进 路线规划 完成 后，在第一阶段 ，比如 对一个 老的应用系统 进行 迁移 或者 一个 全新 的业务系统 进行 微服务架构 开发 ，那么 我们 就需要 基于 这个 实际 的需求 来分析 如何 进行 微服务架构 的实施 ？ 

里面 的关键点 仍然 是如何 划分 不同 的微服务 模块 ？ 

如何 定义 清楚 微服务 模块 间的接口 关系 ？ 

如何 拆分 好不同 的数据库 ？ 

这些 顶层设计 工作 都必须 在前期 做完。

对于 咨询 规划 阶段 ，重点 应该 包括 如下 几个 方面 的关键 内容

1.微服务 模块 如何 拆分 ，其中 包括 了业务 模块 的拆分 ，包括 业务 模块 对应 数据库 拆分

2.在拆分 过程 中，微服务 接口 API 如何识别和定义 ，微服务 模块 间的接口 集成 关系 是如何 的？

3.平台 层能力 如何识别，共性 能力 如何 下沉 ，包括 了技术中台+业务中台。

4. 基于 微服务架构 模式 下整体 应用架构，技术架构，集成 架构 ，数据架构的规划 是如何 的？

5. 基于 微服务架构 下的开发 标准 ，规范 体系

6.基于 微服务架构 下的项目管理 ，过程管理 ，运维 治理 规范 体系 。

微服务架构 -开发 和构建

开发 和构建 实际上 最好 的方法 是，我们 只进行 类似 4A，流程引擎，MDM 主数据 等平台 层微服务 模块 的开发 ，而对于 业务 类微服务 模块 只是 划分 清楚 模块 ，定义 好接口 ，而实际 的开发 则转给 企业内部开发人员 或其他 开发商 进行 。 

而我们 需要 做的就是 整体 的项目群管理 ，后期 的多个 微服务 模块 间的集成 。

即我们 拆分 好微服务 模块 和数据库 ，定义 了一套 标准规范 体系 和技术 开发框架，然后 找了不同 的开发商 来进行 多个 微服务 模块 的开发 ，我们 最终 要保证 开发 完成 的内容 能够 完整 的集成 起来 ，并满足 端到端业务流程 的需要 。 

同时 我们 会实施 一套 过程 支撑 工具 来实现 对DevOps过程 的可视化 支撑 ，通过 过程 支撑 工具 可以 实现 对整个 应用开发 的完全 自动化 ，可视化管理 能力 。

而这些 需求 或特性 要求 刚好 就是 微服务 本身 的特点 ，那么 自然 引出 微服务架构 。

方式 二是 先介绍 微服务架构 。

即整体 方案 里面 先对 微服务架构 做一个简单 的介绍 ，解释 清楚 什么是 单体 应用 ，什么是 微服务架构 ，微服务架构 的核心是什么？ 

其次 解释 清楚 微服务架构 和SOA的关系 。

对于 微服务架构 进一步 解释 清楚 判断 的标准 是什么 ？

同时 要说明 清楚 ，要实现 一个 完整 的微服务架构 ，需要 满足 哪些 判断 准则 ，同时 在微服务架构 里面 有哪些 关键 的核心 组件 ，这些 组件 是起什么作用？ 

具体 选用 的标准 是什么 ？

微服务架构 业界 通用 的一个 定义 是如何 的？

微服务架构 的判断 标准 和准则 ，可以 表格 化来说明 。 

微服务架构 实现 中最基础 要具备 的能力 (开发框架，注册中心 ，负载均衡 ，服务 网关 ，流控 +熔断 ，安全 ）。

微服务架构 化和传统 企业 业务系统 间SOA集成 的差别 在哪里 ？

实际上 我们 看到 最主要 的就是 SOA集成 思路 深入 到了 业务系统 的内部 ，业务系统 本身 的各个 组件 变化 为微服务 模块 ，共性 组件 变化 为采用 平台 层能力 ，微服务 模块 间通过 Rest接口 服务 集成 。

如果 单业务系统 还是 一个 厂商 来做，实际上 单业务系统 本身 就是 一个 SpingCLoud框架 体系 ，通过 服务 网关 发布 接口 服务能力，同时 将接口 服务 进一步 注册 到跨系统 的轻量 SOA服务 总线 上面 来。 

即实际上 的接口 服务 集成 可以 理解 为两层 的集成 ，内部 仍然 可以 走注册中心 点对点 集成 ，有需要 发布 到外的通过 微服务网关通过 二次 注册 将能力 发布 出来 。

一个 企业 应该 如何 实施 微服务架构 ？

微服务架构 更多 是要给技术 词汇 ，但是 微服务 本身 的建设 和实施 就变成了一个 完整 覆盖 从需求 提出 到开发 实施 ，再到部署 交付 ，最后 管控 治理 运维 的全生命周期 管理 。 

实际上 在前面一篇文章 里面 已经 谈到 ，应该 包括 了咨询 和规划 ，开发 和构建 ，管控 和治理 三个 方面 的内容 。 

后续 的介绍 可以 围绕 这三个 方面 的内容 展开 。

注意 ：这里 应该 有一个 完整 的阶段 模式 的流程图 来说明 ，一个 完整 的微服务架构 规划 建设 和实施 过程 是如何 的，即包括 了前期 的规划 阶段 ，开发 建设 阶段 ，后续 的运维 治理 阶段 。 

要体现 每个 阶段 究竟 是完成 什么 关键 工作 ，每个 阶段 是如何 衔接 的。

这张图 实际上 相当 关键 ，即后续 你要 展开 描述 的内容 都应该 在这 张图 上有 体现 。

比如 在我做数字化转型 整体规划 方法论 的时候 ，给出 了一个 覆盖 计划 启动 ，场景 分析 ，业务 建模 ，