微服务架构培训笔记20191108

微服务架构培训笔记20191108

  • 微服务架构概念介绍
    • 微服务架构中文定义
    • 单体应用特点
    • 单体应用缺点
    • 微服务特点
    • 服务标准
    • 服务级别
    • 服务表现形式
    • 微服务的好处
    • 微服务面临的挑战
    • 价值 VS 复杂度
    • 对微服务的常见认识误区
    • 总结
  • 微服务可视化架构设计
    • C4
  • 微服务架构演进
    • 扩展立方体
  • 微服务设计模式
  • 微服务拆分
    • 服务拆分前提
    • 服务拆分时机
    • 拆分规范
  • 微服务迁移
  • 微服务集成
    • 系统集成基础
    • RPC V.S. REST
    • 总结
  • 微服务架构治理
    • 事务场景
      • 本地事务
      • ACID
      • 分布式事务
  • 微服务测试
  • 微服务部署

微服务架构概念介绍

微服务架构中文定义

微服务架构是一种架构模式,它提倡将单一应用划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够背独立的部署到生产环境、类生产环境等。 另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。

单体应用特点

微服务架构培训笔记20191108_第1张图片

单体应用缺点

微服务架构培训笔记20191108_第2张图片

微服务特点

微服务架构培训笔记20191108_第3张图片

服务标准

  • 服务无状态
  • 服务可重用
  • 服务可发现
  • 服务自治
  • 服务松耦合

服务级别

  • 一级服务 – 具备完善的容错机制,定期压测,高级别 监控报警流程
  • 二级服务 – 采用异步方式进行系统交互,容忍数据不 一致性
  • 三级服务 – 可随时为整体服务降级

服务表现形式

具有统一的表现形式,具备契约化的约束条件

  • 服务契约化
    API l 能力描述 l 约束说明
  • 文档服务
    OpenAPI l Swagger

微服务的好处

  • 简化服务开发和部署
  • 更容易接纳不同的技术
  • 业务特性独立升级
  1. 微服务架构可以在单领域实现单特性独立的升级
  2. 对于在单一领域内的多特性,微服务架构是可以支持独立升级的
  3. 对于跨多个领域服务的多特性,升级工作仍然会有较大的波及范围。从软件设计的角度可以解决这个问题。
  • 服务可以独立部署和扩展
  • 安全性和灵活性更高
  • 功能可组合性
  • 可以实现团队自治

微服务面临的挑战

  • 服务的拆分和定义困难
  • 复杂度很大,选择太多
  • 部署的实例多
  • 构建具备弹性的分布式系统复杂
  • 监控复杂
  • 实施周期长

价值 VS 复杂度

微服务架构培训笔记20191108_第4张图片

对微服务的常见认识误区

微服务架构培训笔记20191108_第5张图片

总结

  • 微服务的目标诉求是为了提供响应力
  • 它围绕业务能力进行构建,让一切去中心化是微服务的高宗旨
  • 微服务实施需要具备前提条件,并根据不同的上下文采用不同的迁移路

微服务可视化架构设计

C4

C4 模型由一系列分层的软件架构图组成,这些架构图用于描述系统上下文(context)、容器(containers)、组件(components)和代码(codes)。 C4 图的层次结构提供了不同的抽象级别,每种 抽象级别都与不同的受众有关。

微服务架构演进

扩展立方体

X Y Z 轴

  • X 服务和数据的水平复制 通过克隆实例的方式扩展
  • Y 又称功能性分解 通过分解不同功能的方式来实现扩展
  • Z 又称为数据分区 按数据优先级,类似客户ID的方式,把相似的数据分区进行扩展

微服务设计模式

六种微服务架构的设计模式,在微服务实践过程中抽象出来的纯粹的模式

  1. 共享数据微服务设计模式
  2. 聚合器微服务设计模式
  3. 代理微服务设计模式
  4. 链式微服务设计模式
  5. 分支微服务设计模式
  6. 异步消息微服务

微服务拆分

服务拆分前提

  1. 要有一个持续集成的平台,使得服务在拆分的过程中,功能的一致性,这种一致性不能通过人的经验来,而需要经过大量的回归测试集,并且持续的拆分,持续的演进,持续的集成,从而保证系统时刻处于可以验证交付的状态, 而非闭门拆分一段时间,终谁也不知道功能终究竟有没有bug,因而需要另外一个月的时间专门修改bug。
  2. 在接入层,API和UI要动静分离,API由API网关统一的管理,这样后端无论如何拆分,可以保证对于前端来讲,统 一的入口,而且可以实现拆分过程中的灰度发布,路由分发,流量切分,从而保证拆分的平滑进行。而且拆分后的 微服务之间,为了高性能,是不建议每次调用都进行认证鉴权的,而是在API网关上做统一的认证鉴权,一旦进入网 关,服务之间的调用就是可信的。
  3. 对于数据库,需要进行良好的设计,不应该有大量的联合查询,而是将数据库当成一个简单的key-value查询,复杂 的联合查询通过应用层,或者通过Elasticsearch进行。如果数据库表之间耦合的非常严重,其实服务拆分是拆不出 来的。
  4. 要做应用的无状态化,只有无状态的应用,才能横向扩展,这样拆分才有意义。

服务拆分时机

微服务架构培训笔记20191108_第6张图片

拆分规范

| 拆分的层次
l 仅仅单向调用,严禁循环调用
l 将串行调用改为并行调用,或者异步化
l 接口应该实现幂等
l 接口数据定义严禁内嵌,透传
l 规范化工程名

微服务迁移

微服务集成

系统集成基础

微服务架构培训笔记20191108_第7张图片

RPC V.S. REST

微服务架构培训笔记20191108_第8张图片

总结

  • 微服务拆分和集成构成了从单体系统型微服务系统转换过程中基本的切入点。从服务拆分角度看,我们需要明确 拆分的维度、策略并处理好服务与服务之间以及服务与数据之间的关系
  • 对于服务集成而言,重点关注接口集成
  • 其他数据集成、客户端集成和外部集成等多种策略融合在实际迁移的过程中

微服务架构治理

  • 服务注册核心功能
    确定IP和端口
    优雅上线和下线
    服务健康检查
  • 服务发布订阅流程
  • 服务发布流程
  • 服务发现和调用
  • 服务监控

事务场景

本地事务

 关系型数据库面临了哪些挑战:

l 高并发 一个典型的就是电商网站,例如双11,几亿大军的点击造成在某一时刻的并发量是很 高的,传统的关系型数据库肯定已经是不堪重负了,如Oracle的Session数量推荐的才只 有500。
l 高效率存储海量数据 大数据时代,数据量已经不是用GB、TB来衡量了,而是EB、ZB了,面对这海量的数据, 如何高效率的存储这些数据,关系型数据库无法解决这个问题,以Oracle为例,单机的 物理扩展不仅成本高,而且难度也加大了。
l 高可用&高扩展

ACID

微服务架构培训笔记20191108_第9张图片

分布式事务

分布式事务是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念 扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。分布式事 务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或 回滚事务的决定必须产生统一的结果(全部提交或全部回滚)

微服务测试

微服务部署

你可能感兴趣的:(微服务)