云原生时代已经到来, 你还不心动? Service Mesh Istio dapr 整起
2021-05-28 13:47:51 3 举报AI智能生成
云原生到底是什么? 当前微服务架构大行其道为啥还需架构的进一步升级? 云原生到底帮助解决了什么问题? Service Mesh 当下有哪些 实现, 如何使用. Istio, dapr 案例搭建. 让云原生飞起来...
作者其他创作
大纲/内容
软件服务架构的演进
原分布式时代
背景
20世纪80年代硬件资源逐渐由大型机转化为微型机,单台的机器运算能力非常有限, 8086
摸索
为了突破硬件算力的限制, 各大组织机构开始寻求一些能让多台单个机器协作来完成一套软件系统的运行方案.
这个阶段是对分布式系统设计最原始的一次探索
这个阶段是对分布式系统设计最原始的一次探索
单体系统时代
系统中的主要过程都是在进程内进行调用, 是今天绝大多数的学习和实践的架构风格
这是一个相对小型的系统, 便于开发, 测试, 部署; 各个模块按照包进行组织, 都在进程内部进行调用, 不存在进程间的通讯
从横向的角度考虑, 单体架构也按照技术功能职责进行了管理, 例如java web常见的 mvc三层架构
问题
当业务逻辑过于复杂, 维护起来尤其难受
无法做到快速迭代快速发布, 快速响应
隔离能力缺失, 会导致错误无法阻断, 技术异构困难, 而且只能使用统一的语言 一致的框架, 进而导致工程的局限性
没有自治的能力, 当单体应用宕机之后, 无法自己启动; 或者由统一的应用管理平台来进行打理
SOA时代
烟囱式架构
所有的系统都本地实现所有的功能, 系统与系统之间没有交互. 系统之间无法沟通, 必然导致了它的快速终结
微内核架构
把一些公共的模块, 数据, 服务抽取出来 集中在一起形成一个所有业务共同的依赖核心, 具体的业务按照插件的形式存在. 这样已经做到了可扩展, 灵活的隔离的能力
问题
随着业务的发展, 核心模块越来越庞大, 必将导致 核心系统走向单体架构的老路.
插件之间无法交互, 也是在独立出来的系统需要考虑的问题
事件驱动架构
为了让子系统能互相通讯, 有一种可行的方案就是在子系统之间建立一套事件队列管道. 子系统从管道中获取自己感兴趣的事件消息
SOA时代
SOA中的很多概念在今天的微服务中已经有了雏形, 例如: 服务的注册, 发现, 治理, 编排
SOA有Open CSA组织的加持下, 希望得到一套自上而下软件研发标准, 各个组件之间可以互相缜密的合作. 只要按照这个标准进行, 就可以解决掉所有的软件开发问题
问题
也正是由于行业巨头厂商标准的制定, 定义下严格规范, 过于理想化, 而导致系统结构的过度复杂, 学习实践的成本非常之高
经典的案例就是 EJB, 虽然有SUN, IBM都巨头在背后力挺, 但是仍然失败与 Spring, Mybatis 这类的"亲民的框架"
结论
不管是技术还是其他事物, 一旦脱离的人民群众, 必将淹没在人民群众之中
微服务时代
定义
是一种多个小型服务组合来构建单个应用的架构风格, 特点小而专, 解决单点问题, 可以跨语言问题, 服务通讯问题, 服务治理 等问题
特点
围绕业务能力构建系统
按照业务,规模 动态规划团队. 所有相关人员围绕该业务协助沟通; 避免跨部门沟通
分散治理
各个团队只需要关心自己的业务项目, 保证自己服务质量即可
RPC实现服务通讯
产品化思维模式
避免把软件研发视为完成某种特定的功能, 而是当做一个可以持续改进, 提升的过程
数据去中心化
容错性设计
基础设施自动化
问题
对于软件本身开发的角度来说复杂度是降低的, 但是对于整体的架构设计部署运维造成较大的成本和学习梯度.
当架构者在做决策权衡的, 有大多的因素需要考虑, 太多的已有的框架进行选择. 对于架构者的能力需要很高的要求
当架构者在做决策权衡的, 有大多的因素需要考虑, 太多的已有的框架进行选择. 对于架构者的能力需要很高的要求
在各个技术细节领域, 没有统一的标准之后, 大家就 "八仙过海各显神通" 了, 出现了爆发式的重复造轮子, 造成资源过载
比如针对服务调用就有如下的解决方案: RMI(SUN) , Dubbo, gPRC, bRPC, REST, Fegin等
比如针对服务调用就有如下的解决方案: RMI(SUN) , Dubbo, gPRC, bRPC, REST, Fegin等
随着服务越来越多, 每个服务的实例也越来越多, 服务的拓扑图将边的异常复杂, 难以为继.
云原生时代
思考
微服务基础能力下沉
在分布式架构系统中, 需要解决的问题基本上在微服务时代以软件的形式得到了解决. 比如:服务注册发现, 负载均衡, 传通讯等. 那么我们能不能思考把这些能力下沉到基础组件中, 并且对于业务系统透明呢.
以docker为代表的容器化技术, 在这个时代得到了前所未见的推进. 2017年这个关键节点, Kubernetes在容器化技术中展露锋芒, 在众多"容器编排"战争中获取统治地位. 意味着容器发展中一个时代的终结, 也将是软件架构下一个纪元的开始.
Kubernetes 已经做到了哪些
Kubernetes VS Spring Cloud
诞生
Kubernetes 并不能解决所有的分布式系统中的问题, 例如: 服务降级熔断, 服务的认证授权等细颗粒度的精细化作业方面不能做的尽善尽美, 于是容器化基础设施进行了二次进化
定义
自2013年首次提出 云原生 到2018 年CNCF对云原生的重新定义 意味着这个思想一直在摸索修正进化阶段
云原生: 构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段可实现频繁变更, 组织于 新型动态的云环境中
主要的技术包括: 容器化, 服务网格, 微服务, 不可变基础设施, 声明式API
主要的技术包括: 容器化, 服务网格, 微服务, 不可变基础设施, 声明式API
自己理解
服务架构的指导, 是一个方法论. 应用原生被设计为在云上以最佳方式运行，充分发挥云的优势。
云原生 = 容器化+微服务+不可变基础设施+服务网格
云原生技术图谱
CNCF云原生技术图谱Landscape
Service Mesh
服务网格是一个专用的基础设施层, 它允许您透明地添加可观察性、流量管理和安全性等功能. 可以无感的在应用中添加 这项功能, 对应用没有任何侵入性
Sidecar Proxy
Istio Sidecar Proxy 模型
特点
当我们启动一个Sidecar Proxy之后, 对于应用是透明的, 我们完全不需要在我的业务应用中关心微服务那些基础设施. 例如: 服务之间的通讯鉴权, 细颗粒度的负载均衡等
当然我们可以设计成基于K8s的Pod 自动启动一个Sidecar.
当然我们可以设计成基于K8s的Pod 自动启动一个Sidecar.
在Java生态占优的情况下, 其他语言想加入微服务的俱乐部相对困难. 需要一个更好的底层基础设施来完成这个任务. 从而发挥出每个语言的优势
不论微服务的数量有多少, Service Mesh 控制平面能够展现所有服务的网络拓扑, 并且能进行流量代理控制
落地
已经落地Service Mesh 的公司
无服务时代
定义
Serverless, 如果说微服务是分布式系统这条路的极致, 那么无服务架构, 也许就是 "不分布式" 云端系统这条路的起点
内容
后端即服务 BaaS
类似 数据库, 日志, 消息队列, 缓存 等这一类支持业务运行的基础设施, 本身无关于业务, 部署在云中. 称之为 后端即服务
函数即服务 FaaS
业务逻辑代码, 不必考虑算力, 并发, 扩容 等问题. 称之为 函数即服务
特点
适用于 离线计算的大规模计算, 并且擅长短连接, 无状态, 适合时间驱动的交互形式;
对于交互复杂, 业务逻辑功能强大, 类似信息管理系统, 大小网络游戏等应用 依赖于服务状态, 响应速度, 需要长连接的应用并不适用于无服务
对于交互复杂, 业务逻辑功能强大, 类似信息管理系统, 大小网络游戏等应用 依赖于服务状态, 响应速度, 需要长连接的应用并不适用于无服务
演进总结
随着软件不断的推陈出新, 软件架构迭代的过程其实就是解决当下架构存在的问题和弊端以及优化效率的过程, 让开发专注于业务.
分布式系统的关注点
生命周期
三个部分
应用打包的格式
应用依赖的生态系统
运行时环境
以目前的SpringBoot项目为例: 现在springboot打包的格式为 jar, maven的依赖项作为生态系统, 最终是在JVM上运行
现如今, 随着编译发布周期的缩短. 生命周期中, 我们着重需要关心的是 快速自动部署, 故障恢复, 扩展的能力.
这组功能广泛地代表了我们的应用的生命周期需求
这组功能广泛地代表了我们的应用的生命周期需求
网络
多数应用都需要给其他应用提供服务能力, 或者需要调用第三方服务, 就不可避免的需要牵扯到网络的问题.
那么具体体现在分布式的工程中, 诸如: 服务注册与发现, 服务治理 , 负载均衡, 降级, 熔断, 超时处理 等
状态
通常我们设计部署应用程序的时候. 需要尽量设计成 [无状态] 服务, 这样可以便于迁移, 复制, 扩展.
管理服务的平台需要状态, 需要了解每个服务的运行状态. 这对于执行可靠的服务编排, 单服务实例, 幂等, 临时调度 等等问题是必须的.
所以应用服务的状态进行抽取和监控 需要我们关心
所以应用服务的状态进行抽取和监控 需要我们关心
绑定
分布式系统之间不仅仅需要对话, 还需跟不同的组件进行交互. 例如: 消息的发布/订阅, 轮询, 事件驱动
架构师角度需解决的分布式问题
服务间的交互
HTTP
MQ
事务处理
本地事务
ACID
全局事务
2PC
3PC
分布式事务
事务最终一致性
TCC
SAGA事务
透明的多级分流系统
客户端缓存
域名解析
传输链路
内容分发网络
负载均衡
服务端缓存
架构安全性
服务认证
授权
秘钥安全
传输
验证
云原生下流行的技术
Istio
定义
在应用之上提供一层流量代理能力, 对应用程序透明. 可以进行服务之间通讯的身份验证和授权, 提供负载均衡, 可以流量的精细化管理的能力 一种服务网格的具体实现
官方解释
组成
控制平面
用于配置编排应用代理层, 展现可视化服务视图, 可动态对应用的流量进行规制配置和更新
数据平面
处理服务间的通讯以及跟控制平面之间的通讯. 其实就是对应用透明的流量代理层. 就是我们所谓的 边车代理
运行第一Istio应用
安装
设置
部署应用
示例服务架构图
istio控制台
dapr
0 条评论
下一页
