做一个后台项目的架构

  1. 后台架构的11个维度

    1. 架构1:团队协助基础工具链的选型和培训
    2. 架构2:搭建微服务开发基础设施
    3. 架构3:选择合适的RPC框架
    4. 架构4:选择和搭建高可用的注册中心
    5. 架构5:选择和搭建高可用的配置中心
    6. 架构6:选择和搭建高性能的缓存中间件
    7. 架构7:选择和搭建高性能的消息中间件
    8. 架构8:选择和搭建高性能的关系数据库
    9. 架构9:CICD发布系统/部署系统的架构
    10. 架构10:360度全方位监控和维护的架构
    11. 架构11:生产环境高并发高吞吐负载均衡部署架构
  2. 整个后台技术架构,主要包括 4 个层面的内容:

    1. 语言:用了哪些开发语言,如:C++/Java/Go/PHP/Python/Ruby 等等;
    2. 组件:用了哪些组件,如:MQ 组件,数据库组件等等;
    3. 流程:怎样的流程和规范,如:开发流程,项目流程,发布流程,监控告警流程,代码规范等等;
    4. 系统:系统化建设,上面的流程需要有系统来保证,如:规范发布流程的发布系统,代码管理系统等等;
    5. 在这里插入图片描述
  3. 团队协助基础工具链的选型和培训

    1. 团队协助基础工具链, 主要是三大管理
      1. 项目管理
      2. 任务管理
      3. 问题管理
    2. 项目管理软件是整个业务的需求,问题,流程等等的集中地,大家的跨部门沟通协同大多依赖于项目管理工具
      1. Jira:用 Java 开发的,有用户故事,task 拆分,燃尽图等等,可以做项目管理,也可以应用于跨部门沟通场景,较强大;
      2. Redmine:用 Ruby 开发的,有较多的插件可以使用,能自定义字段,集成了项目管理,Bug 问题跟踪,WIKI 等功能,不过好多插件 N 年没有更新了
      3. Phabricator:用 PHP 开发的,Facebook 之前的内部工具,开发这工具的哥们离职后自己搞了一个公司专门做这个软件,集成了代码托管, Code Review,任务管理,文档管理,问题跟踪等功能,强烈推荐较敏捷的团队使用
  4. 搭建微服务开发基础设施

    1. 搭建微服务开发基础设施需要考虑多个方面,包括但不限于以下几点:
      1. 选择合适的微服务框架和技术栈:目前比较流行的微服务框架有 Spring Cloud、Go-Micro、gRPC等,选择适合自己团队技术栈的框架非常重要
      2. 选择合适的RPC框架
      3. 构建基础设施:包括但不限于服务注册与发现、负载均衡、API 网关、分布式配置中心、分布式锁、消息队列等
      4. 安全:包括但不限于服务间通信的加密、访问控制、身份认证等。
    2. 在搭建微服务开发基础设施之前,需要对自己的业务场景进行分析和规划,确定需要哪些基础设施和技术栈,然后再逐步实现。同时,需要注重可扩展性和可维护性,以便在业务发展过程中能够快速适应变化。
  5. 选择合适的微服务框架和技术栈

    1. 选择合适的微服务框架和技术栈需要考虑多个因素,包括以下几个方面:
      1. 业务需求:不同的业务需求需要不同的技术栈和框架来支持。比如,如果需要高并发和高可用性,可以选择使用 Go 语言和 Kubernetes 等技术来构建微服务。
      2. 开发团队技能:选择的技术栈和框架应该符合开发团队的技能水平,以便开发人员能够快速上手并高效开发
      3. 社区支持:选择流行的技术栈和框架可以获得更好的社区支持,能够更快地解决问题和获得更新的功能
      4. 性能和稳定性:选择的技术栈和框架应该具有良好的性能和稳定性,以便能够支持高负载和长时间运行
    2. 常见的微服务框架和技术栈包括
      1. Spring Cloud:适用于 Java 开发团队,具有丰富的功能和社区支持
      2. Go Micro:适用于 Go 开发团队,具有高性能和简单易用的特点。
      3. Node.js + Express:适用于 JavaScript 开发团队,具有轻量级和快速开发的特点。
      4. Kubernetes:适用于需要高可用性和弹性的微服务架构,可以支持多种编程语言和框架。
      5. Istio:适用于需要服务网格功能的微服务架构,可以提供流量管理、安全性和可观察性等功能
    3. 建议选用 SpringCloud Alibaba+ Dubbo RPC + Dubbo-Go,两个原因
      1. 高性能: 性能测试案例中, Dubbo比Feign性能 强10倍,
      2. 兼顾团队技术栈: 可以跨Go 和Java 多语言微服务架构,Java技术栈的,可以基于 Java开发业务微服务,这块侧重业务开发,Go 技术栈的,可以基于 Go 开发高性能的 技术微服务,这块侧重技术开发和性能优化
      3. 功能和性能兼顾: Java侧重功能的快速开发, Go侧重性能的快速提升。
  6. 选择合适的RPC框架

    1. 维基百科对 RPC 的定义是:远程过程调用(Remote Procedure Call,RPC)是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程
    2. 通俗来讲,一个完整的 RPC 调用过程,就是 Server 端实现了一个函数,客户端使用 RPC 框架提供的接口,调用这个函数的实现,并获取返回值的过程
    3. 业界 RPC 框架大致分为两大流派,一种侧重跨语言调用,另一种是偏重服务治理
    4. 跨语言调用型RPC
      1. 跨语言调用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。这类 RPC 框架侧重于服务的跨语言调用,能够支持大部分的语言进行语言无关的调用,非常适合多语言调用场景。但这类框架没有服务发现相关机制,实际使用时需要代理层进行请求转发和负载均衡策略控制
      2. 其中,gRPC 是 Google 开发的高性能、通用的开源 RPC 框架,其由 Google 主要面向移动应用开发并基于 HTTP/2 协议标准而设计,基于 ProtoBuf(Protocol Buffers)序列化协议开发,且支持众多开发语言。本身它不是分布式的,所以要实现框架的功能需要进一步的开发。
      3. Hprose(High Performance Remote Object Service Engine)是一个 MIT 开源许可的新型轻量级跨语言跨平台的面向对象的高性能远程动态通讯中间件。
    5. 冶理型 RPC
      1. 服务治理型的 RPC 框架的特点是功能丰富,提供高性能的远程调用、服务发现及服务治理能力,适用于大型服务的服务解耦及服务治理,对于特定语言(Java)的项目可以实现透明化接入。缺点是语言耦合度较高,跨语言支持难度较大
      2. 国内常见的冶理型 RPC 框架如下
        1. Dubbo:Dubbo 是阿里巴巴公司开源的一个 Java 高性能优秀的服务框架,使得应用可通过高性能的RPC 实现服务的输出和输入功能,可以和 Spring 框架无缝集成。当年在淘宝内部,Dubbo 由于跟淘宝另一个类似的框架 HSF 有竞争关系,导致 Dubbo 团队解散,最近又活过来了,有专职同学投入。
        2. DubboX:DubboX 是由当当在基于 Dubbo 框架扩展的一个 RPC 框架,支持 REST 风格的远程调用、Kryo/FST 序列化,增加了一些新的feature。
        3. Motan:Motan 是新浪微博开源的一个 Java 框架。它诞生的比较晚,起于 2013 年,2016 年 5 月开源。Motan 在微博平台中已经广泛应用,每天为数百个服务完成近千亿次的调用
        4. rpcx:rpcx 是一个类似阿里巴巴 Dubbo 和微博 Motan 的分布式的 RPC 服务框架,基于 Golang net/rpc 实现。
        5. 但是 rpcx 基本只有一个人在维护,没有完善的社区,使用前要慎重
      3. 建议选用Dubbo,两个原因
        1. 高性能: 性能测试案例中, Dubbo比Feign性能 强10倍
        2. 跨语言: 可以跨Go 和Java 进行 双语言的 RPC调用,从而实现 多语言微服务架构。
    6. 选择和搭建高可用的注册中心
      1. 名字发现和服务发现分为两种模式,一个是客户端发现模式,一种是服务端发现模式。框架中常用的服务发现是客户端发现模式
      2. 所谓服务端发现模式是指客户端通过一个负载均衡器向服务发送请求,负载均衡器查询服务注册表并把请求路由到一台可用的服务实例上。现在常用的负载均衡器都是此类模式,常用于微服务中
      3. 所有的名字发现和服务发现都要依赖于一个可用性非常高的服务注册表,业界常用的服务注册表有如下三个
        1. etcd,一个高可用、分布式、一致性、key-value 方式的存储,被用在分享配置和服务发现中。两个著名的项目使用了它:Kubernetes 和 Cloud Foundry
        2. Consul,一个发现和配置服务的工具,为客户端注册和发现服务提供了API,Consul还可以通过执行健康检查决定服务的可用性
        3. Apache ZooKeeper,是一个广泛使用、高性能的针对分布式应用的协调服务。Apache ZooKeeper 本来是 Hadoop 的子工程,现在已经是顶级工程了
        4. 除此之外还有eureka, nacos等,大家可以根据相关的组件特性,选择适合自己的组件。
      4. 选择和搭建高可用的注册中心,需要考虑以下几个方面
        1. 功能需求:选择注册中心时,需要根据自己的业务需求来选择,比如服务发现、负载均衡、配置管理等。
        2. 性能要求:注册中心需要具备高性能,能够支持高并发、高吞吐量的请求
        3. 可用性要求:注册中心需要具备高可用性,能够保证24小时不间断运行,避免因为单点故障导致整个系统不可用
        4. 安全要求:注册中心需要具备一定的安全性,能够保证数据的机密性和完整性,避免数据泄露和篡改
      5. 常见的注册中心有 ZooKeeper、Etcd、Consul 等,它们都具备高可用性和安全性,并且都支持服务发现和配置管理等功能。其中,ZooKeeper 是最早的分布式协调服务,具备成熟的生态系统和广泛的应用场景;Etcd 是 CoreOS 推出的开源分布式键值存储系统,具备高可用性和一致性保证;Consul 是HashiCorp 推出的服务发现和配置管理工具,具备易用性和可扩展性
      6. 在搭建高可用的注册中心时,需要采用集群部署的方式,避免单点故障。同时,为了保证数据的安全性,可以启用 SSL/TLS 加密功能,并采用访问控制机制来限制访问权限
  7. 选择和搭建统一配置中心

    1. 随着程序功能的日益复杂,程序的配置日益增多:各种功能的开关、降级开关,灰度开关,参数的配置、服务器的地址、数据库配置等等,除此之外,对后台程序配置的要求也越来越高:配置修改后实时生效,灰度发布,分环境、分用户,分集群管理配置,完善的权限、审核机制等等,在这样的大环境下,传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求,需要统一的、基础的配置系统
    2. 统一配置系统是指在一个大型系统中,将所有的配置信息集中管理,以便于对系统进行管理和维护。常见的统一配置系统架构包括以下几个组件
      1. 配置中心:用于存储和管理所有的配置信息,提供配置查询、修改、删除等功能
      2. 配置客户端:用于从配置中心获取配置信息,并将其应用到系统中
      3. 配置发布工具:用于将配置信息发布到配置中心,以便于配置客户端获取。
      4. 配置管理工具:用于对配置信息进行管理和维护,包括配置的新增、修改、删除等操作
      5. 配置监控工具:用于监控配置信息的变化,及时发现并处理配置信息的异常情况
    3. 在实际应用中,可以选择使用开源的配置中心工具,如 ZooKeeper、Etcd、Consul 、Nacos、Apollo等,也可以自己开发一套配置中心系统
    4. 同时,还需要根据实际情况选择合适的配置客户端和配置发布工具。在配置管理和监控方面,可以使用一些开源的工具或者自己开发一套系统。总之,统一配置系统的架构需要根据实际需求进行设计和选择
  8. 选择和搭建高性能的缓存中间件

    1. 选择和搭建高性能的缓存中间件需要考虑多个因素,包括性能、可靠性、可扩展性、易用性等。以下是一些常见的高性能缓存中间件:
      1. Redis:Redis 是一个开源的高性能缓存和键值存储系统,支持多种数据结构,包括字符串、哈希、列表、集合和有序集合等。Redis 通过将数据存储在内存中来提高性能,同时支持数据持久化和集群模式
      2. Memcached:Memcached 是一个开源的高性能分布式内存对象缓存系统,可以缓存任何可序列化的数据,如数据库查询结果、API 响应等。Memcached 可以通过多个节点组成的集群来提高可扩展性和可靠性
      3. Hazelcast:Hazelcast 是一个开源的分布式内存数据网格系统,支持缓存、分布式数据结构和分布式计算等功能。Hazelcast 可以通过多个节点组成的集群来提高可扩展性和可靠性
      4. Couchbase:Couchbase 是一个开源的分布式 NoSQL 数据库和缓存系统,可以缓存任何类型的数据,包括 JSON 文档、键值对和二进制数据等。Couchbase 支持多个节点组成的集群和数据持久化等功能
    2. 在搭建高性能缓存中间件时,需要考虑以下几个方面:
      1. 硬件配置:缓存中间件需要占用大量内存,因此需要配置足够的内存和处理器资源
      2. 部署架构:需要考虑缓存中间件的部署架构,如单节点、主从复制、集群等
      3. 数据持久化:需要考虑数据持久化的方式,如内存快照、AOF 日志、RDB 文件等
      4. 安全性:需要考虑缓存中间件的安全性,如访问控制、数据加密等
      5. 监控和管理:需要考虑缓存中间件的监控和管理,如性能监控、故障诊断等
    3. 建议是 高可用的redis cluster
      1. 要特别注意的是, redis 关系到系统的 高可用, 很容易出生产事故
      2. 如果 redis 出现bigkey,在 高并发场景下, 很容易出现 系统瘫痪, 严重影响系统的可用性
      3. 为大key申请专用的单机节点走主从模式
  9. 选择和搭建高性能的消息中间件

    1. 消息中间件在后台系统中是必不可少的一个组件,一般我们会在以下场景中使用消息中间件
      1. 异步处理:异步处理是使用消息中间件的一个主要原因,在工作中最常见的异步场景有用户注册成功后需要发送注册成功邮件、缓存过期时先返回老的数据,然后异步更新缓存、异步写日志等等;通过异步处理,可以减少主流程的等待响应时间,让非主流程或者非重要业务通过消息中间件做集中的异步处理
      2. 系统解耦:比如在电商系统中,当用户成功支付完成订单后,需要将支付结果给通知ERP系统、发票系统、WMS、推荐系统、搜索系统、风控系统等进行业务处理;这些业务处理不需要实时处理、不需要强一致,只需要最终一致性即可,因此可以通过消息中间件进行系统解耦。通过这种系统解耦还可以应对未来不明确的系统需求
      3. 削峰填谷:当系统遇到大流量时,监控图上会看到一个一个的山峰样的流量图,通过使用消息中间件将大流量的请求放入队列,通过消费者程序将队列中的处理请求慢慢消化,达到消峰填谷的效果。最典型的场景是秒杀系统,在电商的秒杀系统中下单服务往往会是系统的瓶颈,因为下单需要对库存等做数据库操作,需要保证强一致性,此时使用消息中间件进行下单排队和流控,让下单服务慢慢把队列中的单处理完,保护下单服务,以达到削峰填谷的作用
    2. 业界消息中间件是一个非常通用的东西,大家在做选型时有使用开源的,也有自己造轮子的,甚至有直接用 MySQL 或 Redis 做队列的,关键看是否满足你的需求
    3. 选择合适的消息中间件需要考虑多个因素,包括但不限于:
      1. 需要处理的消息数量和频率
      2. 消息的大小和格式
      3. 可用性和容错性要求
      4. 数据安全性和加密需求
      5. 扩展性和灵活性要求
      6. 开发语言和技术栈的兼容性
    4. 常见的消息中间件包括RocketMQ、Kafka、 RabbitMQ、Kafka、ActiveMQ、Redis、NATS 等,每种中间件都有其特点和适用场景
    5. 如果需要处理大量的消息并且需要高吞吐量和低延迟,可以考虑使用 Kafka。如果需要实时处理消息并且需要高可用性和容错性,可以考虑使用 RabbitMQ。如果需要处理轻量级的消息,并且需要高性能和低延迟,可以考虑使用 Redis。
  10. 选择和搭建高性能的关系数据库

    1. 关系数据库分为两种,一种是传统关系数据,如 Oracle,MySQL,Maria,DB2,PostgreSQL 等等,另一种是 NewSQL,即至少要满足以下五点的新型关系数据库
      1. 完整地支持 SQL,支持 JOIN / GROUP BY /子查询等复杂 SQL 查询。
      2. 支持传统数据标配的 ACID 事务,支持强隔离级别
      3. 具有弹性伸缩的能力,扩容缩容对于业务层完全透明
      4. 真正的高可用,异地多活、故障恢复的过程不需要人为的接入,系统能够自动地容灾和进行强一致的数据恢复
      5. 具备一定的大数据分析能力
    2. 传统关系数据库用得最多的是 MySQL,成熟,稳定,一些基本的需求都能满足,在一定数据量级之前基本单机传统数据库都可以搞定,而且现在较多的开源系统都是基于 MySQL,开箱即用,再加上主从同步和前端缓存,百万 pv 的应用都可以搞定了
    3. 不过 CentOS 7 已经放弃了 MySQL,而改使用 MariaDB。MariaDB 数据库管理系统是 MySQ L的一个分支,主要由开源社区在维护,采用 GPL 授权许可。开发这个分支的原因之一是:甲骨文公司收购了MySQL 后,有将 MySQL 闭源的潜在风险,因此社区采用分支的方式来避开这个风险
    4. 在 Google 发布了 F1: A Distributed SQL Database That Scales 和 Spanner: Google’s GloballyDistributed Databasa 之后,业界开始流行起 NewSQL。于是有了 CockroachDB,于是有了奇叔公司的 TiDB
  11. 选择和搭建高性能的NoSQL

    1. NoSQL 顾名思义就是 Not-Only SQL,也有人说是 No – SQL,个人偏向于 Not-Only SQL,它并不是用来替代关系库,而是作为关系型数据库的补充而存在
    2. 常见 NoSQL 有4个类型
      1. 键值,适用于内容缓存,适合混合工作负载并发高扩展要求大的数据集,其优点是简单,查询速度快,缺点是缺少结构化数据,常见的有 Redis,Memcache,BerkeleyDB 和 Voldemort 等等
      2. 列式,以列簇式存储,将同一列数据存在一起,常见于分布式的文件系统,其中以 Hbase,Cassandra 为代表。Cassandra 多用于写多读少的场景,国内用得比较多的有 360,大概 1500台机器的集群,国外大规模使用的公司比较多,如 eBay,Instagram,Apple 和沃尔玛等等
      3. 文档,数据存储方案非常适用承载大量不相关且结构差别很大的复杂信息。性能介于 kv 和关系数据库之间,它的灵感来于 lotus notes,常见的有 MongoDB,CouchDB 等等
      4. 图形,图形数据库擅长处理任何涉及关系的状况。社交网络,推荐系统等。专注于构建关系图谱,需要对整个图做计算才能得出结果,不容易做分布式的集群方案,常见的有 Neo4J,InfoGrid等
    3. 除了以上4种类型,还有一些特种的数据库,如对象数据库,XML 数据库,这些都有针对性对某些存储类型做了优化的数据库。
    4. 在实际应用场景中,何时使用关系数据库,何时使用 NoSQL,使用哪种类型的数据库,这是我们在做架构选型时一个非常重要的考量,甚至会影响整个架构的方案。
  12. CICD发布系统/部署系统的架构

    1. 软件生产的层面看,代码到最终服务的典型流程如图 所示

    2. 在这里插入图片描述

    3. 从上图中可以看出,从开发人员写下代码到服务最终用户是一个漫长过程,整体可以分成三个阶段:

      1. 从代码(Code)到制品库(Artifact)这个阶段主要对开发人员的代码做持续构建,并把构建产生的制品集中管理,是为部署系统准备输入内容的阶段。
      2. 从制品到可运行服务 这个阶段主要完成制品部署到指定环境,是部署系统的最基本工作内容
      3. 从开发环境到最终生产环境 这个阶段主要完成一次变更在不同环境的迁移,是部署系统上线最终服务的核心能力
      4. 发布系统集成了制品管理,发布流程,权限控制,线上环境版本变更,灰度发布,线上服务回滚等几方面的内容,是开发人员工作结晶最终呈现的重要通道
      5. CI/CD 发布系统/部署系统的架构通常包括以下组件:
        1. 源代码管理系统:例如 Git、SVN 等,用于管理代码库
        2. 持续集成工具:例如 Jenkins、GitLab CI、Travis CI 等,用于自动化构建、测试和打包应用程序
        3. 制品仓库:例如 Docker Hub、Harbor、Aliyun Container Registry 等,用于存储应用程序的镜像
        4. 部署工具:例如 Kubernetes、Docker Swarm、Mesos 等,用于自动化部署应用程序
      6. 这些组件可以根据实际需求进行选择和组合,形成一个完整的 CI/CD 发布系统/部署系统
      7. 其中,持续集成工具和部署工具是核心组件,它们负责自动化构建、测试、打包和部署应用程序,从而实现快速、可靠、可重复的软件发布流程
      8. 项目初期可以集成 Jenkins + Gitlab + Harbor,以上方案基本包括制品管理,发布流程,权限控制,线上环境版本变更,灰度发布(需要自己实现),线上服务回滚等功能
  13. 代码管理工具选型

    1. 代码是项目的命脉之一,代码管理很重要,常见的考量点包括两块
      1. 安全和权限管理,将代码放到内网并且对于关系公司命脉的核心代码做严格的代码控制和机器的物理隔离
    2. 代码管理工具,Git 作为代码管理的不二之选
    3. GitLab 是当今最火的开源 Git 托管服务端,没有之一,虽然有企业版,但是其社区版基本能满足我们大部分需求,结合 Gerrit 做 Code review,基本就完美了
    4. 当然 GitLab 也有代码对比,但没 Gerrit 直观
    5. Gerrit 比 GitLab 提供了更好的代码检查界面与主线管理体验,更适合在对代码质量有高要求的文化下使用。
  14. 持续集成工具选型

    1. 持续集成简,称 CI(continuous integration),是一种软件开发实践,即团队开发成员经常集成他们的工作,每天可能会发生多次集成
    2. 每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误
    3. 持续集成为研发流程提供了代码分支管理/比对、编译、检查、发布物输出等基础工作,为测试的覆盖率版本编译、生成等提供统一支持
    4. 业界免费的持续集成工具中系统我们有如下一些选择:
      1. Jenkins:Java 写的有强大的插件机制,MIT 协议开源 (免费,定制化程度高,它可以在多台机器上进行分布式地构建和负载测试)。Jenkins 可以算是无所不能,基本没有 Jenkins 做不了的,无论从小型团队到大型团队 Jenkins 都可以搞定。不过如果要大规模使用,还是需要有人力来学习和维护。
      2. TeamCity:TeamCity 与 Jenkins 相比使用更加友好,也是一个高度可定制化的平台。但是用的人多了,TeamCity就要收费了
      3. Strider:Strider 是一个开源的持续集成和部署平台,使用 Node.js 实现,存储使用的是 MongoDB,BSD 许可证,概念上类似 Travis 和Jenkins
      4. GitLab CI:从GitLab 8.0开始,GitLab CI 就已经集成在 GitLab,我们只要在项目中添加一个 .gitlab-ci.yml 文件,然后添加一个 Runner,即可进行持续集成。并且 GitLab 与 Docker 有着非常好的相互协作的能力。
      5. Travis:Travis 和 GitHub 强关联;闭源代码使用 SaaS 还需考虑安全问题;不可定制;开源项目免费,其它收费。
      6. Go:Go 是 ThoughtWorks 公司最新的 Cruise Control 的化身。除了 ThoughtWorks 提供的商业支持,Go 是免费的。它适用于 Windows,Mac 和各种 Linux 发行版
  15. 自动化测试平台的架构

    1. 搭建自动化测试平台需要考虑以下几个方面:
      1. 选择合适的测试框架和工具:可以选择一些流行的测试框架和工具,如Selenium、Appium、JMeter等,根据需要选择适合自己的工具
      2. 搭建测试环境:需要搭建测试环境,包括测试服务器、测试数据库、测试数据等。可以使用虚拟机或者容器来搭建测试环境,以便进行测试。
      3. 编写测试用例:需要编写测试用例,测试用例应该覆盖系统的各个功能点,以便发现潜在的问题
      4. 集成测试工具和测试用例:将测试工具和测试用例集成到自动化测试平台中,以便进行自动化测试。
      5. 运行测试用例:编写好测试用例后,需要运行测试用例,收集测试结果,并生成测试报告。
      6. 定期维护和更新:自动化测试平台需要定期维护和更新,以保证测试环境的稳定性和测试用例的有效性
    2. 可以结合 SpringBoot + TestNG 测试框架,搭建自己的 自动化测试平台
      1. TestNG 是一个开源自动化测试框架;
      2. TestNG 灵感来自 JUnit 和 NUnit,但引入了一些新的功能,使其功能更强大,使用更方便。
      3. TestNG表示下一代(Next Generation的首字母)。
      4. TestNG类似于 JUnit (特别是 JUnit 4),但它不是JUnit框架的扩展。它的目的是优于 JUnit ,尤其是在用于测试集成多类时。
      5. TestNG消除了大部分的旧框架的限制,使开发人员能够编写更加灵活和强大的测试。 因为它在很大程度上借鉴了Java注解( JDK5.0引入的)来定义测试,它也可以显示如何使用这个新功能在真实的 Java 语言生产环境中
    3. 下面的两个 测试平台,就是非常好的 改造项目:
      1. 接口自动化测试框架(java httpClient + testNg)ChenSen5/api_autotest: 接口自动化测试框架(java httpClient + testNg) (github.com)
      2. 基于SpringBoot的高效模板化自动化测试框架 https://github.com/jinganglong123/jg-api-autotest
  16. 360度全方位监控和维护的架构

    1. 360度全方位监控和维护的架构包括
      1. 日志系统
      2. 监控系统
    2. 日志系统
      1. 日志系统一般包括打日志,采集,中转,收集,存储,分析,呈现,搜索还有分发等

      2. 一些特殊的如染色,全链条跟踪或者监控都可能需要依赖于日志系统实现

      3. 日志系统的建设不仅仅是工具的建设,还有规范和组件的建设,最好一些基本的日志在框架和组件层面加就行了,比如全链接跟踪之类的

      4. 对于常规日志系统ELK能满足大部分的需求,ELK 包括如下组件

        1. ElasticSearch 是个开源分布式搜索引擎,它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,RESTful 风格接口,多数据源,自动搜索负载等
        2. Logstash 是一个完全开源的工具,它可以对你的日志进行收集、分析,并将其存储供以后使用。Kibana 是一个开源和免费的工具,它可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web界面,可以帮助汇总、分析和搜索重要数据日志
        3. Filebeat 已经完全替代了 Logstash-Forwarder 成为新一代的日志采集器,同时鉴于它轻量、安全等特点,越来越多人开始使用它
      5. 因为免费的 ELK 没有任何安全机制,所以这里使用了 Nginx 作反向代理,避免用户直接访问 Kibana 服务器。

      6. 加上配置 Nginx 实现简单的用户认证,一定程度上提高安全性

      7. 另外,Nginx 本身具有负载均衡的作用,能够提高系统访问性能。

      8. 在这里插入图片描述

      9. 对于有实时计算的需求,可以使用 Flume + Kafka + Storm + MySQL 方案,一 般架构如图所示

      10. 在这里插入图片描述

      11. Flume 是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的日志收集系统,支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume 提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。

      12. Kafka 是由 Apache 软件基金会开发的一个开源流处理平台,由 Scala 和 Java 编写。其本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”,它以可水平扩展和高吞吐率而被广泛使用。

      13. Kafka 追求的是高吞吐量、高负载,Flume 追求的是数据的多样性,二者结合起来简直完美。

    3. 监控系统
      1. 监控系统只包含与后台相关的,这里主要是两块,一个是操作系统层的监控,比如机器负载,IO,网络流量,CPU,内存等操作系统指标的监控

      2. 另一个是服务质量和业务质量的监控,比如服务的可用性,成功率,失败率,容量,QPS 等等

      3. 常见业务的监控系统先有操作系统层面的监控(这部分较成熟),然后扩展出其它监控,如 Zabbix,小米的 Open-Falcon,也有一出来就是两者都支持的,如 Prometheus

      4. 如果对业务监控要求比较高一些,在创业选型中建议可以优先考虑 Prometheus。

      5. Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库(TSDB)。

      6. Prometheus 使用 Go 语言开发,是 Google BorgMon 监控系统的开源版本。

      7. 相对于其它监控系统使用的 push 数据的方式,Prometheus 使用的是 pull 的方式

      8. 在这里插入图片描述

      9. 如上图所示,Prometheus 包含的主要组件如下:

        1. Prometheus Server 主要负责数据采集和存储,提供 PromQL 查询语言的支持
        2. Server 通过配置文件、文本文件、ZooKeeper、Consul、DNS SRV Lookup 等方式指定抓取目标。
        3. 根据这些目标会,Server 定时去抓取 metrics 数据,每个抓取目标需要暴露一个 http 服务的接口给它定时抓取
        4. 客户端 SDK:官方提供的客户端类库有 Go、Java、Scala、Python、Ruby,其他还有很多第三方开发的类库,支持 Nodejs、PHP、Erlang 等。
        5. Push Gateway 支持临时性 Job 主动推送指标的中间网关。
        6. Exporter 是 Prometheus 的一类数据采集组件的总称。它负责从目标处搜集数据,并将其转化为 Prometheus 支持的格式。
        7. 与传统的数据采集组件不同的是,它并不向中央服务器发送数据,而是等待中央服务器主动前来抓取
        8. Prometheus 提供多种类型的 Exporter 用于采集各种不同服务的运行状态。目前支持的有数据库、硬件、消息中间件、存储系统、HTTP 服务器、JMX 等
        9. Alertmanager:是一个单独的服务,可以支持 Prometheus 的查询语句,提供十分灵活的报警方式。Prometheus HTTP API 的查询方式,自定义所需要的输出
        10. Grafana 是一套开源的分析监视平台,支持 Graphite,InfluxDB,OpenTSDB,Prometheus,Elasticsearch,CloudWatch 等数据源,其 UI 非常漂亮且高度定制化
        11. 创业公司选择 Prometheus + Grafana 的方案,再加上统一的服务框架(如 gRPC),可以满足大部分中小团队的监控需求
  17. 生产环境高并发高吞吐负载均衡部署架构

    1. 高并发高吞吐负载均衡链路架构,包括:

      1. DNS的选型和使用设计
      2. LB(负载均衡)的选型和使用设计
      3. CDN的选型和使用设计
    2. DNS的选型和使用设计

      1. DNS 是一个很通用的服务,创业公司基本上选择一个合适的云厂商就行了,国内主要是两家
      2. 阿里万网:阿里 2014 年收购了万网,整合了其域名服务,最终形成了现在的阿里万网,其中就包含DNS 这块的服务
      3. 腾讯 DNSPod:腾讯 2012 年以 4000 万收购 DNSPod 100% 股份,主要提供域名解析和一些防护功能;
      4. 如果你的业务是在国内,主要就是这两家,选 一个就好,像今日头条这样的企业用的也是 DNSPod 的服务,除非一些特殊的原因才需要自建,比如一些 CDN 厂商,或者对区域有特殊限制的
      5. 要实惠一点用阿里最便宜的基础版就好了,要成功率高一些,还是用 DNSPod 的贵的那种。
      6. 在国外还是选择亚马逊吧,阿里的 DNS 服务只有在日本和美国有节点,东南亚最近才开始部点,DNSPod 也只有美国和日本,像一些出海的企业,其选择的云服务基本都是亚马逊
      7. 如果是线上产品,DNS 强烈建议用付费版,阿里的那几十块钱的付费版基本可以满足需求。如果还需要一些按省份或按区域调试的逻辑,则需要加钱,一年也就几百块,省钱省力
      8. 如果是国外,优先选择亚马逊,如果需要国内外互通并且有自己的 APP 的话,建议还是自己实现一些容灾逻辑或者智能调度,因为没有一个现成的 DNS 服务能同时较好的满足国内外场景,或者用多个域名,不同的域名走不同的 DNS
    3. LB(负载均衡)的选型和使用设计

      1. LB(负载均衡)是一个通用服务,一般云厂商的 LB 服务基本都会如下功能:
        1. 支持四层协议请求(包括 TCP、UDP 协议);
        2. 支持七层协议请求(包括 HTTP、HTTPS 协议);
        3. 集中化的证书管理系统支持 HTTPS 协议
        4. 健康检查;
      2. 如果你线上的服务机器都是用的云服务,并且是在同一个云服务商的话,可以直接使用云服务商提供的LB 服务,如阿里云的 SLB,腾讯云的 CLB,亚马逊的 ELB 等等。如果是自建机房基本都是 LVS +Nginx
    4. CDN的选型和使用设计

      1. 就创业公司来说,CDN 用腾讯云或阿里云即可,其相关系统较完善,能轻松接入,网宿在系统支持层面相对较弱一些,而且还贵一些。并且,当流量上来后,CDN 不能只用一家,需要用多家,不同的CDN 在全国的节点覆盖不一样,而且针对不同的客户云厂商内部有些区分客户集群,并不是全节点覆盖(但有些云厂商说自己是全网节点),除了节点覆盖的问题,多 CDN 也在一定程度上起到容灾的作用

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/309417.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

(七)C++自制植物大战僵尸游戏关卡数据加载代码讲解

植物大战僵尸游戏开发教程专栏地址http://t.csdnimg.cn/xjvbb 打开LevelData.h和LevelData.cpp文件。文件位置如下图所示。 LevelData.h 此头文件中定义了两个类,分别是OpenLevelData、LevelData,其中OpenLevelData用于加载文件数据。LevelData解析数据…

vue中预览docx、xlsx、pptx、pdf

前言:其实本来是要做全类型文件预览的,但是一直找不到合适的doc,xlx,ppt预览插件。要是有可以使用的,可以评论推荐给我 我使用的node版本:v18.19.1 参考官网:preview 文件预览 | ran 引入方式: //安装组…

学习笔记之——3DGS-SLAM系列代码解读

最近对一系列基于3D Gaussian Splatting(3DGS)SLAM的工作的源码进行了测试与解读。为此写下本博客mark一下所有的源码解读以及对应的代码配置与测试记录~ 其中工作1~5的原理解读见博客: 学习笔记之——3D Gaussian Splatting及其在SLAM与自动…

Qt 中默认代码

目录 主函数 widget的声明 widget的定义 form file .pro 文件 主函数 #include "widget.h" ​ #include <QApplication> ​ int main(int argc, char *argv[]) {QApplication a(argc, argv);Widget w;w.show();return a.exec(); } 上面就是 Qt 刚创建的一…

非关系型数据库(缓存数据库)redis的集群

目录 一.群集模式——Cluster 1.原理 2.作用 3.特点 4.工作机制 哈希槽 哈希槽的分配 哈希槽可按照集群主机数平均分配&#xff08;默认分配&#xff09; 根据主机的性能以及功能自定义分配 redis集群的分片 分片 如何找到给定key的分片 优势 二. 搭建Redis群集…

JVM虚拟机(五)强引用、软引用、弱引用、虚引用

目录 一、强引用二、软引用三、弱引用四、虚引用五、总结 引文&#xff1a; 在 Java 中一共存在 4 种引用&#xff1a;强、软、弱、虚。它们主要指的是&#xff0c;在进行垃圾回收的时候&#xff0c;对于不同的引用垃圾回收的情况是不一样的。下面我们就一起来看一下这 4 种引用…

基于R语言实现的负二项回归模型【理解与实现】-理解负二项回归模型和泊松回归模型之间的区别

前言 我们可以在R语言中使用MASS包中的glm.nb函数来拟合负二项模型&#xff0c;以及使用glm函数来拟合泊松模型。以下是一个详细的过程&#xff0c;包括模拟数据的生成、模型的拟合、结果的比较和解释。 需要的包 if (!require("MASS")) install.packages("M…

Linux网络基础 (二) ——(IP、MAC、端口号、TCPUDP协议、网络字节序)

文章目录 IP 地址基本概念源IP地址 & 目的IP地址 MAC 地址基本概念源MAC地址 & 目的MAC地址 端口号基本概念源端口号 & 目的端口号 TCP & UDP 协议基本概念TCP 与 UDP 的抉择 网络字节序大端、小端字节序 &#x1f396; 博主的CSDN主页&#xff1a;Ryan.Alask…

YOLOv8模型剪枝实战:DepGraph(依赖图)方法

课程链接&#xff1a;YOLOv8模型剪枝实战&#xff1a;DepGraph(依赖图)方法_在线视频教程-CSDN程序员研修院 YOLOv8是一个当前非常流行的目标检测器&#xff0c;本课程使用DepGraph&#xff08;依赖图&#xff09;剪枝方法对YOLOv8进行网络剪枝&#xff0c;使其更加轻量和实用…

Qt快速入门(MV架构之TableView + QStandardItemModel + 自定义代理小案例)

Qt快速入门&#xff08;MV架构之TableView QStandardItemModel 自定义代理小案例&#xff09; 关于MV架构的简单介绍 在Qt框架中&#xff0c;代理&#xff08;Delegate&#xff09;、模型&#xff08;Model&#xff09;和视图&#xff08;View&#xff09;之间的关系构成了…

51单片机实验03-单片机定时/计数器实验

目录 一、实验目的 二、实验说明 1、51单片机有两个16位内部计数器/定时器&#xff08;C/T&#xff0c; Counter/Timer&#xff09;。 2、模式寄存器TMOD 1) M1M0工作模式控制位&#xff1b; 2) C/T定时器或计数器选择位&#xff1a; 3&#xff09;GATE定时器/计数器运行…

Python零基础从小白打怪升级中~~~~~~~模块+异常+Pycharm的debug调试

第十节&#xff1a;模块异常Debug 一、Python模块 Python 模块(Module)&#xff0c;是一个 Python 文件&#xff0c;以 .py 结尾&#xff0c;模块能定义函数&#xff0c;类和变量&#xff0c;模块里也能包含可执行的代码。 1、导入模块 导入模块的5中方式 import 模块名fr…

C++ 之 【类与对象】从入门到精通一条龙服务 最终篇(static成员、友元、匿名对象。。。)

&#x1f4b4;到用时方恨早&#xff0c;白首方悔挣的少 车到山前没有路&#xff0c;悬崖勒马勒不住 一、再谈构造函数 1.构造函数体赋值 2.初始化列表 3.explicit关键字 二、Static成员 1.概念 2.特性 三、友元 1.友元函数 2.友元类 四、内部类 五、匿名对象 六、…

结合 tensorflow.js 、opencv.js 与 Ant Design 创建美观且高性能的人脸动捕组件并发布到InsCode

系列文章目录 如何在前端项目中使用opencv.js | opencv.js入门如何使用tensorflow.js实现面部特征点检测tensorflow.js 如何从 public 路径加载人脸特征点检测模型tensorflow.js 如何使用opencv.js通过面部特征点估算脸部姿态并绘制示意图tensorflow.js 使用 opencv.js 将人脸…

模型预测控制MPC(1)—— 基础概念

文章目录 1. 历史沿革1.1 控制论1.2 最优控制与强化学习 2. 模型预测控制 1. 历史沿革 我本科做机器人的时候接触过一点控制&#xff0c;主要做了大量 PID 在嵌入式控制系统的应用&#xff1b;硕士期间研究方向是强化学习。在我调研 MPC 的过程中&#xff0c;发现它同时出现在…

云笔记小程序的实现

1.前言 云笔记, 是基于HotApp小程序统计云后台提供的api接口开发的一个微信小程序。 2.功能 离线保存笔记 云端数据同步, 更换了设备也可以找到以前的笔记 接入了好推二维码提供的数据统计工具, 可以到平台上查看用户分析、留存分析、事件分析。 3.界面效果 ***HotApp云笔…

Redis Pipelining 底层原理分析及实践

作者&#xff1a;vivo 互联网服务器团队-Wang Fei Redis是一种基于客户端-服务端模型以及请求/响应的TCP服务。在遇到批处理命令执行时&#xff0c;Redis提供了Pipelining(管道)来提升批处理性能。本文结合实践分析了Spring Boot框架下Redis的Lettuce客户端和Redisson客户端对…

行云堡垒国密算法应用与信创支持

一、 国密算法和信创的介绍 1.1 什么是国密算法 国密算法是国家密码管理局制定颁布的一系列的密码标准&#xff0c;即已经被国家密码局认定的国产密码算法&#xff0c;又称商用密码&#xff08;是指能够实现商用密码算法的加密&#xff0c;解密和认证等功能的技术&#xff09;…

excel里如何的科学计数法的数字转换成数值?

比如下图&#xff0c;要想把它们转换成3250跟1780&#xff0c;有什么快捷的办法吗&#xff1f; 科学计数法在excel里的格式&#xff0c;与我们常规在数学上写的有差异。这个转换可以这样做&#xff1a; 1.转换后的效果&#xff1a; 2.问题分析 题目中所附截图&#xff0c;单元…

Day96:云上攻防-云原生篇Docker安全系统内核版本漏洞CDK自动利用容器逃逸

目录 云原生-Docker安全-容器逃逸&系统内核漏洞 云原生-Docker安全-容器逃逸&docker版本漏洞 CVE-2019-5736 runC容器逃逸(需要管理员配合触发) CVE-2020-15257 containerd逃逸(启动容器时有前提参数) 云原生-Docker安全-容器逃逸&CDK自动化 知识点&#xff1…