DaoCloud云原生转型实验室首席架构师王天青——微服务架构转型的三大挑战及应对之策
2020-02-27 583浏览
- 1.微服务架构转型的三大挑战及应对之策 王天青 首席架构师， DaoCloud云原生转型实验室
- 2.About Me • 南京大学计算机科学与技术系硕士。 • 资深Java程序员，2003年开始从事J2EE开发，从软件开发做到架构设计。 • 08年加入EMC中国研究院，最高担任云平台主任研究员，长期从事云计算 创新技术解决方案设计和实现。 • 2015年9月加入麻袋理财，任首席架构师 • 2016年12月加入DaoCloud，任首席架构师，负责云原生应用转型实验室 • 在工作期间，分别在中国和美国提交了20+专利申请，其中7项专利被美国 专利局正式授权。
- 3.为什么要用微服务架构？ 移动互联网时代的挑战 我要支持100万客户！！！ 又快又好 公司IT投入怎么比业务发展快？？？
- 4.为什么要用微服务架构？ 独角兽的成功秘诀 • Speed of innovation （天下武功，唯快不破） • Always-available services （随时、随地可用） • Web scale（从0到1，快速扩展） • Mobile-centric user experiences （移动为王）
- 5.软件架构比较 单体 vs. SOA vs. 微服务架构 优势 劣势 • 不够灵活：任何细修改需要将整个应用重新构建/部署，这降低了团队 • 人所众知：传统工具、应用和脚本都是这种结构 的灵活性和功能交付频率 • IDE友好：Eclipse、IntelliJ等开发工具多 • 妨碍持续交付：单体应用比较大时，构建时间比较长，不利于频繁部 单 • 便于共享：单个归档文件包含所有功能，便于共享 署，阻碍持续交付。 体 • 易于测试：单体应用部署后，服务或特性即可展现，没有额外的依 • 受技术栈限制：必须使用同一语言/工具、存储及消息，无法根据具体 赖，测试可以立刻开始 的场景做出其它选择 • 容易部署：只需将单个归档文件复制到单个目录下 • 技术债务：“不坏不修（Not broken，don’t fix）”， 系统设计/代码 难以修改，偶合性高。 • 服务重用性：通过编排你基本服务以用于不同的场景 • 易维护性：单个服务的规模变小，维护相对容易 • 高可靠性：使用消息机制及异步机制，提高了可靠性 SOA • 高扩展和可用性：分布式系统的特性 • 软件质量提升：单个服务的复杂度降低 • 平台无关：可以集成不同的系统 • 提升效率：服务重用、降低复杂性，提升了开发效率 • 过分使用ESB：使得系统集成过于复杂 • 使用基于SOAP协议的WS：使得通信的额外开销很大 • 使用形式化的方式管理：增加了服务管理的复杂度 • 需要使用可靠的ESB：初始投资比较高 • 简单：单个服务简单，只关注于一个业务功能。 微 • 团队独立性：每个微服务可以由不同的团队独立开发。 服 • 松耦合：微服务是松散耦合的。 务 • 平台无关性：微服务可以用不同的语言/工具开发。 • 通信协议轻量级：使用REST或者RPC进行服务间通信 • 运维成本过高 • 分布式系统的复杂性 • 异步，消息与并行方式使得系统的开发门槛增加 • 分布式系统的复杂性也会让系统的测试变得复杂
- 6.挑战之一：什么场景使用微服务架构？ 人人都在谈微服务，我也要上微服务 • 场景一 • 2B场景 • 用户数量是1W • 迭代周期半年 • 场景二 • 需要集成多个系统 • 各个系统接口不一样 业务驱动技术，技术推动业务
- 7.挑战一：应对之策 两个维度：创新速度 + 用户数量 快： 只争朝夕 教育 创 娱乐 工作 效率 新 信息 速 度 用户数量 多： 海量用户
- 8.挑战二：研发如何落地微服务？ 人人都在谈微服务框架，用了就算落地了
- 9.挑战二：应对之策之业务梳理 业务梳理 • 首先要理解业务，理解需求 • 需求要文档化，要明确业务场景，业务流程等信息
- 10.挑战二：应对之策之领域设计 领域驱动设计（Domain Driven Design） • 领域 • 子领域 • 上下文 • 通用语言 • 实体 • 值对象 • 聚合 • 领域事件 • 服务 • 存储库 • 模块
- 11.挑战二：应对之策之系统设计 非功能性需求及关注地图 可用性 性能 伸缩性 扩展性 安全 速度 RO I 质量 架构 开发 测试 D evOp s 架构 开发 测试 D evOp s 模块化 领域模型 接口测试 CI 高可用 编码规范 自动化测试 系统监控 服务化 系统设计 集成测试 CD 高性能 单元测试 代码覆盖率 应用监控 微服务 接口设计 系统测试 自动化 高伸缩 代码评审 分支覆盖率 业务监控
- 12.挑战三：微服务如何上生产？ 只要能够部署到生产服务器上就足够了 • 服务特性 • 单体的项目拆分成了若干个服务 • 服务之间启动有依赖关系 • 服务需要依赖第三方中间件服务 • 部署方式 • 手工或者脚本部署
- 13.挑战三：应对之策之云原生应用 黄金三角 微服务架构 敏捷的 基础架构 精益研发流程 1. DevOps 2. 持续交付 Cloud Native Application Cloud Native describes the patterns of high performing organizations delivering software faster, consistently and reliably at scale. （又快又好） Why, how and what of the cloud natives： Continuous delivery DevOps Microservices
- 14.挑战三：应对之策之DevOps 持续交付流水线 8. Git tag 1. Merge dev branch to uat branch Git (Maven) Build (Maven) Deploy 环境A 微服务 A B C D E F 6. Deploy (Docker) Build/Push (Docker) Deploy 7. Test TC TC TC Integration Test Git-flow 3. Maven deploy4. Docker build 2. Maven package Maven （ Nexus（ 5. Docker push Docker Registry 环境B 微服务 A B C D E F
- 15.挑战三：应对之策之容器管理平台 轻量级弹性容器基础架构 • 服务编排 • 服务注册与发现 • 负载均衡 • 自动伸缩 • 监控告警 • 日志
- 16.挑战三：应对之策之容器管理平台 轻量级弹性容器基础架构 负载均衡 开发流程 标准应用 标准应用 标准应用 负载均衡 标准应用 标准应用 标准应用 负载均衡 标准应用 标准应用 标准应用 开发 环境 测试环境数据 测试 环境 测试环境数据 生产 环境 生产环境数据 代码仓库 自构动建构规建则 开发 环境 应用镜像 应用镜像 镜像 仓库 统一应用运行平台 测试 环境 权限控制 生产 环境 发布规则
- 17.总结 转型流程 1. 业务架构梳 理 2. 领域设计 3. 系统设计 4. 微服务开发 框架引入 5. 微服务基础 设施构建 9. 微服务运维 基础设施构建 8. 容器管理平 台集成 7. 应用容器化 6. DevOps自 动化流程集成
- 18.总结 流程说明 业务架构梳理 领域设计 系统设计 微服务开发框架引入 微服务基础设施构建 DevOps自动化流程集成 应用容器化 容器管理平台集成 微服务运维基础设施构建 •输出PRD文档，包括业务规则，业务流程图等 •使用Domain-Driven-Design设计原则，划分系统层次，领域边界等 •根据领域设计输出，定义不同的服务及其职责 •使用Spring Boot／Cloud建立服务代码框架 •根据需求构建配置中心，注册中心，熔断器，系统管理等微服务基础设施 •构建持续集成和持续发布体系，同时划分开发，测试，生产环境 •构建基础镜像和应用镜像，同时DevOps自动化流程集成对容器的支持 •使用DCE对生产容器集群进行管理 •应用运维与容器管理平台集成
- 19.Q&A
