云架构.

云原生

什么是云原生：

  1. 云原生是一系列云计算技术体系和企业管理方法的集合，既包括了实现应用云原生的方法论，也包含了落地实践的关键技术。
  2. “适合云的应用，好用的云架构”

云原生应用对比传统应用有什么优势？

  1. 云原生应用
    • 可预测。
    • 操作系统抽象化。
    • 合适的容量。
    • 协作。
    • 持续交付
    • 独立
    • 自动化可扩展性。
    • 快速恢复。
  2. 传统应用
    • 不可预测。
    • 依赖操作系统。
    • 过多容量。
    • 孤立。
    • 瀑布式开发。
    • 依赖。
    • 手动扩展。
    • 恢复缓慢。

技术概述

  • 云并非把原先在物理服务器上跑的东西放到虚拟机里跑，真正的云化不仅是基础设施和平台的事情，应用也要做出改变，改变传统的做法，实现云化的应用 应用的架构、应用的开发方式、应用部署和维护技术都要做出改变，真正的发挥云的弹性、动态调度、自动伸缩 一些传统 IT 所不具备的能力。这里说的“云化的应用”也就是“云原生应用”
  • 云原生架构和云原生应用所涉及的技术很多， 其关键技术如 容器技术、微服务、可持续交付、DevOps 等

微服务

  • 微服务是什么： 微服务是指将大型复杂软件应用拆分成多个简单应用，每个简单应用描述着一个小业务，系统中的各个简单应用可被独立部署。各个微服务之间是松耦合的，可以独立地对每个服务进行升级、部署、扩展和重新启动等流程，从而实现频繁更新而不会对最终用户产生任何影响。相比传统的单体架构，微服务架构具有降低系统复杂度、独立部署、独立扩展、跨语言编程等特点。

容器化

容器技术-资源调度、微服务更容易

  • 容器是一种轻量级的虚拟化技术，能够在单一主机上提供多个隔离的操作系统环境，通过一系列的namespace进行进程隔离，每个容器都有唯一的可写文件系统和资源配额。

  • 微服务架构天然适合用容器为载体，容器是一种轻量级的虚拟化技术，能够在单一主机上提供多个格力的操作系统环境。

  • 容器技术分为运行时和编排两层，运行时负责容器的计算、存储、网络等等，编排层负责容器集群的调度、服务发现和资源管理

  • 容器服务简化了容器管理集群的搭建工作，整合了调度、配置、存储、网络等，打造云端最佳容器运行环境。使用容器技术，用户可以将微服务及其所需的所有配置，依赖关系和环境变量打包成容器镜像，轻松移植到全新的服务器节点上，而无需重新配置环境，这使得容器成为部署单个微服务的最理想工具。

DevOps

  • Devops是一组过程，方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、写作与整合：以终为始，运维合一。
  • 开发和运维看似是两个貌似互相矛盾的角色。因为开发负责业务的持续迭代，会为系统引入大量 的变更，如果系统正在稳定运行，那么每次上线和发布都给系统带来新的风险。而运维追求的是 系统可用性、而变更就意味着可能带来的不稳定。
  • 在DevOp5的能力闭环中[如上图]，关注的是： ■ 更早、更频繁地发布产品更新，永远bea版，更快速的响应变化。 ■ 依托自动化工具测试、部署]，把开发、测试、发布、部署的过程整合，实现即时交付。
  • 如要具备此能力，就要求DV0p5的涉众：开发、测试、运维，求同存异，为组织目标共同担当， 紧密配合，提升产品交付能力
  • DevOps Research and Assessment (DORA) 的DevOps研究报告显示，通过对多达25,000职业技术人员的调研，发现践行了DevOps的高效能人员相比于低效者，在很多方面都展现出很大的优势
  • DevOps流程包括“计划-需求-设计-开发-部署-运营”，其中涉及到敏捷，持续交付、精益、ITSM 等知识领域。
  • DevOps工具链中包括版本控制&协作开发工具、自动化构建和测试工具、持续集成&交付工具、 部署工具、维护工具、监控，警告&分析工具等。不同企业根据其开发流程和团队架构需要构建 适合自己的DeV0p5工具链。
  • 腾讯云的TAPD产品支持主流代码、构建、自动化测试、部署发布工具，帮助企业实现研发工具 链整合，打破平台壁垒。并可以将流程数据可视化与管理，帮助团队成员快速掌握流水线执行情 况，定位失败原因，快速响应与反馈集成工具如下：
    1. 代码集成工具：腾讯工蜂、Gitlab、Github。
    2. 代码检测集成工具：SonarQube、几eXu5。持续集成与交付集成工具：Jenkins、Gitlab CI、Ansible。
    3. 自动化测试集成工具：JUnit、PHP Unit、Python Unit Test。

持续交付

  • 传统的应用生命周期为：需求-设计-开发-测试-部署/运维-监控/运营，将应用做整体交付
  • 持续交付更多倾向于敏捷的工作方式，不求大而全，以最小可行性产品为交付单位，在交付的过程中不断接受反馈并完善，将“应用生命周期：需求-设计-开发-测试-部署/运维-监控/运营”变成一个循环往复的闭环。持续交付要求构建一个部署管道，允许版本控制系统中的每个更改通过标准的自动化过程提交到测试环境，再经过自动化测试后部署到生产环境。
  • 持续交付可以实现快速交付、快速反馈、降低发布风险。
  • 构建自己的CI/CD持续构建管道与发布流程，如使用Jenkins。

在腾讯云上实现微服务架构

云原生架构的基本特征：容器化、微服务、使用Api、使用最佳语言和框架、使用DevOps。

微服务城建框架

Spring Cloud

  • 要实现微服务，有什么工具可以利用？
  • Spring Cloud,是目前实现微服务的架构的主流框架之一，是一系列框架的有序集合，它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发。Spirng Cloud占据着微服务市场的主流地位，它甚至一度成为微服务的代名词。
  • 由于JaVa语言的便捷以及Spring框架的普及，当前这种模式的微服务框架是业界使用最广泛的微服务框架。传统行业中，对于那种本身是基于J归Va&5prng开发的应用、或者新开发的应用，基本上都首选采用该微服务框架来进行改造。

Service Mesh

  • SerVⅵce mesh处理服务间请求/响应的可靠传递，并可用于服务治理、遗留系统的零侵入接入以及异构框架开发的微服务
  • 以Spring Cloud为代表的微服务框架不能解决所有问题，对于一些类似传统银行、敏感机关、或 者小型企业的行业客户，其应用的特点具备跨语言、应用改造流程复杂、线上节点替换升级风险 大、/SV技术积累较浅的特质。在这种情况下，往往难以说服他们使用框架5DK进行改造。
  • 在这种背景下，催生了下一代微服务架构Sevicemesh,一种基于外置sidecari模式的微服务框架。其架构特点是把微服务框架的能力移到了微服务外部，作为独立的sidecar,进程来提供。微服务之间通过sidecari透明代理的方式来进行通信。使得服务开发者只需要聚焦业务本身，服务可随意跨语言实现。而在升级过程中，sidecar可以独立升级，无需与微服务进行联动替换。从而解决了第二代框架所遗留的问题。

微服务的设计原则

  • AKF拆分原则、前后端分离、无服务状态、Re5 tful APl通信
  • 领域驱动设计：https://www.infoq.cn/article/s_LFUlU6ZQODd030RbH9
  • 业务领域蓝图：DDD的全称为Domain-driven Design,即领域驱动设计；领域驱动设计[DDD]
  • 告诉我们的最大价值我觉得是：当我们要开发一个系统时，应该尽量先把领域模型想清楚，然后
  • 再开始动手编码，这样的系统后期才会很好维护
  • 全维度可视化：从不同维度实现可视化，如T5F中提供了服务拓扑，服务监控，调用链等
  • 全流程自动化：自动化一切可以自动化的，降低部署和发布的难度
  • 容错设计：自动容错设计，如熔断器，集群
  • 去中心化设计：提供服务的扩展能力
  • 独立部署：服务可以独立部署

基于TSF 的微服务设计原则

TSF是什么

  1. 围绕应用和微服务的Paa5平台。
  2. 提供服务全生命周期管理能力和数据化运营支持。
  3. 提供多维度应用、服务、机器的监控数据，助力服务性能优化。
  4. 拥抱Spring Cloud、Service mesh微服务框架。
  5. 让企业轻松构建大型分布式系统。

基于TSF的微服务设计原则

  1. TSF与全维度可视化
  2. TSF与全流程自动化（devops）
  3. TSF与微服务容错平台
  4. TSF与微服务去中心化设计
  5. TSF与平台去中心化设计
  6. TSF与独立部署

TSF与全维度可视化

  1. 调用链查询用来查询和定位具体某一次调用的情况。使用者可以通过具体的服务、接口定位、IP等来查询具体的调用过程，查找调用过程所需要的时间和运行情况。
  2. 通过调用链详情，可以根据TraceID查询调用链的详细信息。调用链详情是为了定位再分布式链路调用过程中每个还记得耗时和异常（不包含本地调用情况，本地方法调用建议使用业务Log的方式记录）。
  3. 通过调用链通常为了解决如下几个问题：
    1. 定位好事较长的业务
    2. 不合理的调用逻辑（如一次请求多次调用某服务，建议改为批量调用接口）
  4. 可以在服务治理中通过服务拓扑图中的颜色块区别正常与异常访问的请求，请求可视化，具体日志方式可以方便快速的定位问题点。

TSF与DevOps

在TSF中把基础框架构建全部通过自动化框架代码生成，开发人员只需要引入代码就可以快速完成基础框架代码构建，让发人员更多的关注业务。

在测试过程中，把单元测试，集成测试，回归测试等通过自动化测试工具完成，同时实现灰度发布，自动回滚功能，相比原有传统方式大大减少了工作量。

TSF与微服务容错设计

  1. 优雅的服务降级：微服务架构的最大优点之一是您可以隔离故障，并在当组件单独故障时，进行 优雅的服务降级。 例如，在中断期间，照片共享应用程序中的客户可能无法上传新图片，但仍可 以浏览，编辑和共享其现有照片
  2. 变更管理：在微服务架构中，服务依赖于彼此。要处理变更中的问题，您可以实施变更管理策略和自动回滚机制
  3. 健康检查与负载均衡：实例由于出现故障、部署或自动缩放的情况，会进行持续启动、重新启动或停止操作。它可能导致它们暂时或永久不可用。为避免问题，您的负载均衡器应该从路由中跳过不健康的实例，应用实例健康状况可以通过外部观察来确定。您可以通过重复调用 GET/health 端点或通过自我报告来实现。现在主流的服务发现解决方案，会持续从实例中收集健康信息，并配置负载均衡，将流量仅路由到健康的组件上
  4. 自我修复：可以帮助应用程序从错误中恢复过来。当应用程序可以采取必要步骤从故障状态恢复时，我们就可以说它是可以实现自我修复的
  5. 故障转移缓存：由于网络问题和我们系统的变化，服务经常会失败。然而，由于自我修复和负载均衡的保障，它们中的大多数中断是临时的，我们应该找到一个解决方案，使我们的服务在这些故障时服务仍就可以工作。这就是故障转移缓存的作用，它可以帮助并为我们的应用程序在服务故障时提供必要的数据
  6. 重试逻辑：在某些情况下，我们无法缓存数据，或者我们想对其进行更改，但是我们的操作最终都失败了。对于此，我们可以重试我们的操作，因为我们可以预期资源将在一段时间后恢复，或者我们的负载均衡器将请求发送到了健康的实例上
  7. 限流器和负载降级：通过流量限制，您可以过滤掉造成流量峰值的服务，或者您可以确保您的应用程序在自动缩放无法满足时，依然不会超载
  8. 快速失败原则与独立性 在微服务种通过使用超时来达到快速失败的效果是一种反模式的，你应该避免使用它。取而代之，您可以应用断路器模式，依据操作的成功与失败统计数据决定
  9. 舱壁模式：工业中使用舱壁将船舶划分为几个部分，以便在船体破坏的情况下，可以将船舶各个部件密封起来；舱壁的概念在软件开发中可以被应用在隔离资源上
  10. 断路器：当特定类型的错误在短时间内多次发生时，断路器会被断开。开路的断路器可以防止进一步的请求 就像我们平时所说的电路跳闸一样。断路器通常在一定时间后关闭，在这期间可以为底层服务提供足够的空间来恢复
  11. 测试故障： 经常测试故障，让您的团队具备故障处理的能力。

TSF与微服务去中心化设计

传统外包业务

微服务外包业务流程

1、需求整理需要一次性清晰，反复修改成本高
2、业务微小变化，需要整体系统重构，或数据库无法支特
3、老系统代码基本无法复用，开发成本高，收益时间短
4、外包的人力和选择强绑定，更换代价大

1、基于业务领域设计需求，逐渐在使用中清晰化功能
2、业务变化，最小粒度基于接☐招标，人力外包
3、开放的系统架构下，代码复用能力强，企业具备自主开发能力，更新迭代速度块，不停服的进行更新
4、人力外包灵活选择，质优价廉。

梳理业务流程
梳理业务功能点
系统重构/新建
输出系统需求
输出招投标
外包人力中标开发
验收软件

基于业务领域〔DDD]进行微服务模块设计
基于整体架构设计接☐文档
基于整体架构设计开发规范
基于每个功能模块招标开发
外包人力中标-微服务开发
接口验收-灰度上线

业务流程方面也由传统的外包模式业务转变为微服务业务流程，基于业务领域设计原则，提供代 码复用能力，让企业更多的关注新业务；

Serverless架构介绍

无服务器计算[Serverless Computing]是指在构建和运行应用时无需管理服务器等基础设施。它描述了一个更细粒度的部署模型，在该模型中，应用被拆解为一个或多个细粒度的函数被上传到一个平台，然后根据当前所需执行、扩展和计费。

  • 消除了对传统的海量持续在线服务器组件的需求
  • 降低了开发和运维的复杂性
  • 降低运营成本并缩短了业务系统的交付周期
  1. Serverless架构如何降低开发、运维的复杂性和T运营成本？服务器操作。无服务器通过消除维护服务器资源所涉及的开销，极大地改变了运行软件应用程序的成本模型。没有配置、更新和管理服务器基础结构。
  2. 弹性伸缩：无服务器Faa5或Baa5产品可以立即精确地伸缩以处理每个单独的传入请求。对于开发人员来说，无服务器平台没有“预先计划的容量”的概念，也不需要配置“自动伸缩”触发器或规则。在没有开发人员干预的情况下，自动进行缩放。在完成请求处理后，无服务器Faa5会自动缩小计算资源的规模，以确保永远没有空闲的容量。
  3. 低成本。无服务器计算服务对空闲的虚拟机或容器不收费，也就是说当代码没有运行或没有进行有意义的工作时，不收费。-CNCF,《Serverless Whitepaper》

Serverless架构组件

无服务器架构与主流部署形态的对比

虚拟机、容器和 Serverless 都对 IT 基础设施资源做了抽象，但三者之间也存在显著差异。 无服 务器架构并不能够完全替代虚拟机及容器的应用，在部署方式、安全隔离程度、生态完整程度、 场景适用性等方面各有优缺点，拥有各自有的技术受众。

  • 虚拟机部署：稳态业务的首选。低延迟、 可预测的高性能以及更好的隔离环境， 使它成为静 态单体架构应用程序和性能敏感的工作负载， 即高性能计算应用（例如视频编码、 机器学习） 的部署首选。 对于大型应用程序，虚拟机也是最主要的部署对象，特别是强调数据持久性和 有状态应用。
  • 容器部署：微服务架构的最佳载体，容器技术将所有应用都标准化为可管理、可测试、易迁移 的镜像，因此为不同技术栈提供了整合管理的途径
  • 无服务器化部署：事件驱动下的部署新形态

Serverless架构的应用与局限

应用后端服务

移动应用后端服务：使用无服务器架构技术构建移动后端服务是非常常用的场景。它允许开发 人员在基于云平台的后端服务来构建应用。这使得开发人员可以更加专注在移动应用的优化上， 只要按需选择云服务商提供的丰富的后端服务即可。 例如微信小程序的开发 IOT 后端服务：物联网的应用场景中，设备传输数据量小，且往往是以固定时间间隔进行数据 传输， 数据传输存在明显的波峰波谷特征。数据传输的波峰时段触发后端函数服务集中处理， 处理结束后快速释放，提升资源的利用效率。 大规模数据处理和计算类 人工智能推理预测：人工智能的推理预测的调用需求会随着业务的起伏而变化， 具有一定的 波动性。 同时 AI 推理一般会使用 GPU 加速， 这种明显的峰值变化会导致大量的资源浪费。 使用无服务器架构技术可以有效解决上述问题。高业务请求到来时，云函数的执行实例自动扩 容，满足业务需求；请求低谷或无请求到来时，云函数自动缩容，节省资源使用。 批处理或计划任务：每天只需短期运行就能以异步计算的方式进行强大的并行计算能力， IO 或网络访问的任务非常适合无服务器架构。 这些任务可以以弹性方式运行时消费所需的资源， 并且在不被使用的当天剩余时间内不会产生资源成本。 例如定期的数据备份等。 基于事件的内容处理类应用 实时文件处理：有些应用会根据不同的应用需求将图片裁剪成不同尺寸，或添加不同的标签水 印。视频类的应用会将视频流转码成不同的清晰度推送给不同服务。当图片或者视频流通过对 象存储上传时便会触发相应的函数计算，根据计算规则自动按需处理， 整个过程无需再搭建 额外服务器，也无需人工干预。 定制事件触发：以用户注册时发邮件验证邮箱地址的场景举例，可以通过定制的事件来触发后续的注册流程，而无需再配置额外的应用无服务器来处理后续的请求。

局限

  • 现阶段函数即服务的局限性也较为明显。 代码调试较为复杂， FaaS 平台的代码调试大多需要下 载到本地，调试成功后上传至函数，在线调试工具功能尚不完善，调试的复杂度较高；
  • 低延时业务暂不适用， FaaS 中的代码通过事件触发，如果执行结束一段时间没有再次触发，执 行函数的容器会销毁，再次启动会有启动的开销，增加启动延迟，所以目前不适用低延迟的业务，如金融交易等
  • 由于大量 BaaS 服务均由厂商负责维护，这也使得无服务器架构的厂商绑定现象较为严重
  • 目前缺乏标准化和完整的生态系统，缺乏全面，稳定的文档，示例，工具和最佳实践。

腾讯云函数

  • 无服务器云函数（ Serverless Cloud Function SCF ）是腾讯云为企业和开发者们提供的无服 务器执行环境，帮助用户在无需购买和管理服务器的情况下运行代码。 用户只需使用平台支持的 语言编写核心代码并设置代码运行条件，即可在腾讯云基础设施上弹性、安全地运行代码。 SCF 是实时文件处理和数据处理等场景下理想的计算平台。使用云函数时，用户只需关注自己的代码。
  • 腾讯云完全管理底层计算资源，包括服务器 CPU 、内存、网络和其他配置 资源维护、代码部署、弹性伸缩、负载均衡、安全升级、资源运行情况监控等，用户只需使用平台支持的语言提供代码。代码在执行时将根据请求负载扩缩容，无需人工配置和介入即可满足不同情景下服务的可用性和 稳定性，从每天几个请求到每秒数千个请求，都由云函数底层自行伸缩。云函数自动地在地域内 的多个可用区部署，提供极高的容错性。用户只需为运行中的云函数付费，代码未运行时不产生 任何费用。

原理

  1. 调用源：函数调用来源于用户或内部云产品事件触发，当前支持：手动触发（ API ）、定时触发、 COS 触发、 CMQ 触发、 API 网关触发等触发方式
  2. 接入层：负载用户鉴权等问题
  3. 控制层：负载函数调用的分发，函数配置，函数实例生命周期管理，动态扩缩容，容灾调度，负 载均衡等
    • 函数调用：直接使用已有实例，如果实例不足，通过调度创建新实例
    • 函数调度：实例的扩缩容及代码变更
  4. 执行层：负载运行环境，执行用户函数

应用案例

  1. 背景：腾讯相册通过小程序和空间相册打通，实现了在小程序端的照片上传、下载、分享好友、点赞、评论、生成小程序码等功能。
  2. 痛点：
    • 小程序是新项目，人力非常紧缺，后台不能百分百投入
    • 后台系统有历史包袱，新功能开发难度大
    • 采用传统开发模式搭建小程序架构，费时费力。除了数据读取、文件管理、敏感逻辑的处理（如权限）外，还需考虑很多诸如弹性伸缩、容灾、负载均衡等技术问题
  3. 无服务器云函数解决方案：小程序 · 云开发是微信团队和腾讯云联合开发的，集成于小程序控制台的原生 Serverless 云服务。核心功能包括： 云函数、云数据库和云存储。用户只需编写核心逻辑代码，无需关注后端配置与运维，专注于业务开发 。
  4. 以快速上线的点赞评论功能为例，存在如下典型问题：
    • 新增小程序评论、点赞等操作需要用户的鉴权信息；
    • 原有的后端服务架构太复杂，增加新功能非常困难
  5. 经过经由 Serverless 架构构建服务， 利用云函数路由功能，在原有的相册服务端获取用户的鉴权信息，匹配原有后台服务，判断该用户在小程序端是否有权限进行敏感操作，轻松实现业务需求。功能如下
    • 对小程序端评论、点赞等数据进行拉取和存储的操作。
    • 当小程序端进行评论、点赞等操作时，通过云函数的路由功能，在原有的相册服务端获取用户的鉴权信息。

思考

问题一：云原生的关键技术有哪些？

问题二：微服务可以怎样进行拆分？

问题三： Serverless 架构的应用场景有哪些？

答案

问题一：微服务、容器、 CI/CD 、 DevOps

问题二：领域驱动设计、 AKF 扩展模型

问题三：应用后端服务，大规模数据处理和计算类应用，基于事件的内容处理类应用