做一个后台项目的架构

后台架构的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：生产环境高并发高吞吐负载均衡部署架构
整个后台技术架构，主要包括 4 个层面的内容：
1. 语言：用了哪些开发语言，如：C++/Java/Go/PHP/Python/Ruby 等等；
2. 组件：用了哪些组件，如：MQ 组件，数据库组件等等；
3. 流程：怎样的流程和规范，如：开发流程，项目流程，发布流程，监控告警流程，代码规范等等；
4. 系统：系统化建设，上面的流程需要有系统来保证，如：规范发布流程的发布系统，代码管理系统等等；
团队协助基础工具链的选型和培训
1. 团队协助基础工具链，主要是三大管理
  1. 项目管理
  2. 任务管理
  3. 问题管理
2. 项目管理软件是整个业务的需求，问题，流程等等的集中地，大家的跨部门沟通协同大多依赖于项目管理工具
  1. Jira：用 Java 开发的，有用户故事，task 拆分，燃尽图等等，可以做项目管理，也可以应用于跨部门沟通场景，较强大；
  2. Redmine：用 Ruby 开发的，有较多的插件可以使用，能自定义字段，集成了项目管理，Bug 问题跟踪，WIKI 等功能，不过好多插件 N 年没有更新了
  3. Phabricator：用 PHP 开发的，Facebook 之前的内部工具，开发这工具的哥们离职后自己搞了一个公司专门做这个软件，集成了代码托管， Code Review，任务管理，文档管理，问题跟踪等功能，强烈推荐较敏捷的团队使用
搭建微服务开发基础设施
1. 搭建微服务开发基础设施需要考虑多个方面，包括但不限于以下几点：
  1. 选择合适的微服务框架和技术栈：目前比较流行的微服务框架有 Spring Cloud、Go-Micro、gRPC等，选择适合自己团队技术栈的框架非常重要
  2. 选择合适的RPC框架
  3. 构建基础设施：包括但不限于服务注册与发现、负载均衡、API 网关、分布式配置中心、分布式锁、消息队列等
  4. 安全：包括但不限于服务间通信的加密、访问控制、身份认证等。
2. 在搭建微服务开发基础设施之前，需要对自己的业务场景进行分析和规划，确定需要哪些基础设施和技术栈，然后再逐步实现。同时，需要注重可扩展性和可维护性，以便在业务发展过程中能够快速适应变化。
选择合适的微服务框架和技术栈
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侧重性能的快速提升。
选择合适的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 加密功能，并采用访问控制机制来限制访问权限
选择和搭建统一配置中心
1. 随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、降级开关，灰度开关，参数的配置、服务器的地址、数据库配置等等，除此之外，对后台程序配置的要求也越来越高：配置修改后实时生效，灰度发布，分环境、分用户，分集群管理配置，完善的权限、审核机制等等，在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求，需要统一的、基础的配置系统
2. 统一配置系统是指在一个大型系统中，将所有的配置信息集中管理，以便于对系统进行管理和维护。常见的统一配置系统架构包括以下几个组件
  1. 配置中心：用于存储和管理所有的配置信息，提供配置查询、修改、删除等功能
  2. 配置客户端：用于从配置中心获取配置信息，并将其应用到系统中
  3. 配置发布工具：用于将配置信息发布到配置中心，以便于配置客户端获取。
  4. 配置管理工具：用于对配置信息进行管理和维护，包括配置的新增、修改、删除等操作
  5. 配置监控工具：用于监控配置信息的变化，及时发现并处理配置信息的异常情况
3. 在实际应用中，可以选择使用开源的配置中心工具，如 ZooKeeper、Etcd、Consul 、Nacos、Apollo等，也可以自己开发一套配置中心系统
4. 同时，还需要根据实际情况选择合适的配置客户端和配置发布工具。在配置管理和监控方面，可以使用一些开源的工具或者自己开发一套系统。总之，统一配置系统的架构需要根据实际需求进行设计和选择
选择和搭建高性能的缓存中间件
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申请专用的单机节点走主从模式
选择和搭建高性能的消息中间件
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。
选择和搭建高性能的关系数据库
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
选择和搭建高性能的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，使用哪种类型的数据库，这是我们在做架构选型时一个非常重要的考量，甚至会影响整个架构的方案。
CICD发布系统/部署系统的架构
1. 软件生产的层面看，代码到最终服务的典型流程如图所示
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，以上方案基本包括制品管理，发布流程，权限控制，线上环境版本变更，灰度发布（需要自己实现），线上服务回滚等功能
代码管理工具选型
1. 代码是项目的命脉之一，代码管理很重要，常见的考量点包括两块
  1. 安全和权限管理，将代码放到内网并且对于关系公司命脉的核心代码做严格的代码控制和机器的物理隔离
2. 代码管理工具，Git 作为代码管理的不二之选
3. GitLab 是当今最火的开源 Git 托管服务端，没有之一，虽然有企业版，但是其社区版基本能满足我们大部分需求，结合 Gerrit 做 Code review，基本就完美了
4. 当然 GitLab 也有代码对比，但没 Gerrit 直观
5. Gerrit 比 GitLab 提供了更好的代码检查界面与主线管理体验，更适合在对代码质量有高要求的文化下使用。
持续集成工具选型
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 发行版
自动化测试平台的架构
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
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 本身具有负载均衡的作用，能够提高系统访问性能。
  9. 对于有实时计算的需求，可以使用 Flume + Kafka + Storm + MySQL 方案，一般架构如图所示
  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 的方式
  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），可以满足大部分中小团队的监控需求
生产环境高并发高吞吐负载均衡部署架构
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 也在一定程度上起到容灾的作用