linuxnatsphp技巧_从0开始做一个后台项目的架构

对我而言我，我的答案是综合考虑下面的这些内容然后进行决定。

全体后台技能架构，紧张包括 4 个层面的内容：

结合以上的的 4 个层面的内容，全体后台技能栈的构造如图1 所示：

图1 后台技能栈构造

咱们一个个别系和组件的做选型，终极形成我们的后台技能栈。

团队帮忙根本工具链的选型和培训

团队帮忙根本工具链， 紧张是三大管理

项目管理软件是全体业务的需求，问题，流程等等的集中地，大家的跨部门沟通协同大多依赖于项目管理工具。

有一些 SaaS 的项目管理做事可以利用，但是很多韶光不知足需求，此时我们可以选择一些开源的项目，这些项目本身有一定的定制能力，有丰富的插件可以利用，一样平常的创业公司需求基本上都能得到知足，常用的项目如下：

这些平台我都用过，有些乃至还搭建过，惭愧地说一句，盗版的，目前建议是 Jira。
像银行，基本上conflue+jira是标配了。

搭建微做事开拓根本举动步伐

搭建微做事开拓根本举动步伐须要考虑多个方面，包括但不限于以下几点：

在搭建微做事开拓根本举动步伐之前，须要对自己的业务场景进行剖析和方案，确定须要哪些根本举动步伐和技能栈，然后再逐步实现。
同时，须要看重可扩展性和可掩护性，以便在业务发展过程中能够快速适应变革。

选择得当的微做事框架和技能栈

选择得当的微做事框架和技能栈须要考虑多个成分，包括以下几个方面：

常见的微做事框架和技能栈包括：

在选择时，须要根据详细的业务需求和开拓团队技能来选择得当的微做事框架和技能栈。

建议选用 SpringCloud Alibaba+ Dubbo RPC + Dubbo-Go，两个缘故原由：

（1） 高性能：做过的性能测试中， Dubbo比Feign性能 强10倍。

（2） 兼顾团队技能栈：可以跨Go 和Java 多措辞微做事架构，Java技能栈的同学们，可以基于 Java开拓业务微做事，这块侧重业务开拓。
Go 技能栈的同学们，可以基于 Go 开拓高性能的 技能微做事，这块侧重技能开拓和性能优化。

（3）功能和性能兼顾：Java侧重功能的快速开拓， Go侧重性能的快速提升。

选择得当的RPC框架

维基百科对 RPC 的定义是：远程过程调用（Remote Procedure Call，RPC）是一个打算机通信协议。
该协议许可运行于一台打算机的程序调用另一台打算机的子程序，而程序员无需额外地为这个交互浸染编程。

普通来讲，一个完全的 RPC 调用过程，便是 Server 端实现了一个函数，客户端利用 RPC 框架供应的接口，调用这个函数的实现，并获取返回值的过程。

业界 RPC 框架大致分为两大流派，一种侧重跨措辞调用，另一种是侧重做事管理。

跨措辞调用型 RPC：

跨措辞调用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。
这类 RPC 框架侧重于做事的跨措辞调用，能够支持大部分的措辞进行措辞无关的调用，非常适宜多措辞调用场景。
但这类框架没有做事创造干系机制，实际利用时须要代理层进行要求转发和负载均衡策略掌握。

个中，gRPC 是 Google 开拓的高性能、通用的开源 RPC 框架，其由 Google 紧张面向移动运用开拓并基于 HTTP/2 协议标准而设计，基于 ProtoBuf（Protocol Buffers）序列化协议开拓，且支持浩瀚开拓措辞。
本身它不是分布式的，以是要实现框架的功能须要进一步的开拓。

Hprose（High Performance Remote Object Service Engine）是一个 MIT 开源容许的新型轻量级跨措辞跨平台的面向工具的高性能远程动态通讯中间件。

冶理型 RPC：

做事管理型的 RPC 框架的特点是功能丰富，供应高性能的远程调用、做事创造及做事管理能力，适用于大型做事的做事解耦及做事管理，对付特定措辞(Java)的项目可以实现透明化接入。
缺陷是措辞耦合度较高，跨措辞支持难度较大。

海内常见的冶理型 RPC 框架如下：

但是 rpcx 基本只有一个人在掩护，没有完善的社区，利用前要慎重。

建议选用Dubbo，两个缘故原由：

（1） 高性能：性能测试案例中， Dubbo比Feign性能 强10倍

（2） 跨措辞：可以跨Go 和Java 进行 双措辞的 RPC调用，从而实现 多措辞微做事架构。

选择和搭建高可用的注册中央

名字创造和做事创造分为两种模式，一个是客户端创造模式，一种是做事端创造模式。
框架中常用的做事创造是客户端创造模式。

所谓做事端创造模式是指客户端通过一个负载均衡器向做事发送要求，负载均衡器查询做事注册表并把要求路由到一台可用的做事实例上。
现在常用的负载均衡器都是此类模式，常用于微做事中。

所有的名字创造和做事创造都要依赖于一个可用性非常高的做事注册表，业界常用的做事注册表有如下三个：

etcd，一个高可用、分布式、同等性、key-value 办法的存储，被用在分享配置和做事创造中。
两个著名的项目利用了它：Kubernetes 和 Cloud Foundry。
Consul，一个创造和配置做事的工具，为客户端注册和创造做事供应了API，Consul还可以通过实行康健检讨决定做事的可用性。
Apache ZooKeeper，是一个广泛利用、高性能的针对分布式运用的折衷做事。
Apache ZooKeeper 本来是 Hadoop 的子工程，现在已经是顶级工程了。
除此之外还有eureka, nacos等，大家可以根据干系的组件特性，选择适宜自己的组件。

选择和搭建高可用的注册中央，须要考虑以下几个方面：

常见的注册中央有 ZooKeeper、Etcd、Consul 等，它们都具备高可用性和安全性，并且都支持做事创造和配置管理等功能。
个中，ZooKeeper 是最早的分布式折衷做事，具备成熟的生态系统和广泛的运用处景；Etcd 是 CoreOS 推出的开源分布式键值存储系统，具备高可用性和同等性担保；Consul 是 HashiCorp 推出的做事创造和配置管理工具，具备易用性和可扩展性。

在搭建高可用的注册中央时，须要采取集群支配的办法，避免单点故障。
同时，为了担保数据的安全性，可以启用 SSL/TLS 加密功能，并采取访问掌握机制来限定访问权限。

建议是高可用的nacos，也便是 nacos+mysql的版本

选择和搭建统一配置中央

随着程序功能的日益繁芜，程序的配置日益增多：各种功能的开关、降级开关，灰度开关，参数的配置、做事器的地址、数据库配置等等，除此之外，对后台程序配置的哀求也越来越高：配置修正后实时生效，灰度发布，分环境、分用户，分集群管理配置，完善的权限、审核机制等等，在这样的大环境下，传统的通过配置文件、数据库等办法已经越来越无法知足开拓职员对配置管理的需求，须要统一的、根本的配置系统

统一配置系统是指在一个大型系统中，将所有的配置信息集中管理，以便于对系统进行管理和掩护。
常见的统一配置系统架构包括以下几个组件：

在实际运用中，可以选择利用开源的配置中央工具，如 ZooKeeper、Etcd、Consul 、Nacos、Apollo等，也可以自己开拓一套配置中央系统。

同时，还须要根据实际情形选择得当的配置客户端和配置发布工具。
在配置管理和监控方面，可以利用一些开源的工具或者自己开拓一套系统。
总之，统一配置系统的架构须要根据实际需求进行设计和选择。

建议是高可用的nacos，也便是 nacos+mysql的版本

本文福利， 免费领取C/C++ 开拓学习资料包、技能视频/代码，1000道大厂口试题，内容包括（C++根本，网络编程，数据库，中间件，后端开拓，音视频开拓，Qt开拓，游戏开拓，Linux内核等进阶学习资料和最佳学习路线）↓↓↓↓有须要的朋友可以进企鹅裙927239107领取哦~↓↓

选择和搭建高性能的缓存中间件

选择和搭建高性能的缓存中间件须要考虑多个成分，包括性能、可靠性、可扩展性、易用性等。
以下是一些常见的高性能缓存中间件：

Redis：Redis 是一个开源的高性能缓存和键值存储系统，支持多种数据构造，包括字符串、哈希、列表、凑集和有序凑集等。
Redis 通过将数据存储在内存中来提高性能，同时支持数据持久化和集群模式。
Memcached：Memcached 是一个开源的高性能分布式内存工具缓存系统，可以缓存任何可序列化的数据，如数据库查询结果、API 相应等。
Memcached 可以通过多个节点组成的集群来提高可扩展性和可靠性。
Hazelcast：Hazelcast 是一个开源的分布式内存数据网格系统，支持缓存、分布式数据构造和分布式打算等功能。
Hazelcast 可以通过多个节点组成的集群来提高可扩展性和可靠性。
Couchbase：Couchbase 是一个开源的分布式 NoSQL 数据库和缓存系统，可以缓存任何类型的数据，包括 JSON 文档、键值对和二进制数据等。
Couchbase 支持多个节点组成的集群和数据持久化等功能。

在搭建高性能缓存中间件时，须要考虑以下几个方面：

硬件配置：缓存中间件须要占用大量内存，因此须要配置足够的内存和处理器资源。
支配架构：须要考虑缓存中间件的支配架构，如单节点、主从复制、集群等。
数据持久化：须要考虑数据持久化的办法，如内存快照、AOF 日志、RDB 文件等。
安全性：须要考虑缓存中间件的安全性，如访问掌握、数据加密等。
监控和管理：须要考虑缓存中间件的监控和管理，如性能监控、故障诊断等。

总之，选择和搭建高性能缓存中间件须要综合考虑多个成分，根据详细需求和场景进行选择和配置。

建议是高可用的redis cluster

要特殊把稳的是，redis关系到系统的高可用，很随意马虎出生产事件。

如果redis涌现big key，在高并发场景下，很随意马虎涌现系统瘫痪，严重影响系统的可用性，导致系统瘫痪。

选择和搭建高性能的中间件

中间件在后台系统中是必不可少的一个组件，一样平常我们会在以了局景中利用中间件：

异步处理：

异步处理是利用中间件的一个紧张缘故原由，在事情中最常见的异步场景有用户注册成功后须要发送注册成功邮件、缓存过期时先返回老的数据，然后异步更新缓存、异步写日志等等；通过异步处理，可以减少主流程的等待相应韶光，让非主流程或者非主要业务通过中间件做集中的异步处理。

系统解耦：

比如在电商系统中，当用户成功支付完成订单后，须要将支付结果给关照ERP系统、发票系统、WMS、推举系统、搜索系统、风控系统等进行业务处理；这些业务处理不须要实时处理、不须要强同等，只须要终极同等性即可，因此可以通过中间件进行系统解耦。
通过这种系统解耦还可以应对未来不明确的系统需求。

削峰填谷：

当系统碰着大流量时，监控图上会看到一个一个的山峰样的流量图，通过利用中间件将大流量的要求放入行列步队，通过消费者程序将行列步队中的处理要求逐步消化，达到消峰填谷的效果。
最范例的场景是秒杀系统，在电商的秒杀系统中下单做事每每会是系统的瓶颈，由于下单须要对库存等做数据库操作，须要担保强同等性，此时利用中间件进行下单排队和流控，让下单做事逐步把行列步队中的单处理完，保护下单做事，以达到削峰填谷的浸染。

业界中间件是一个非常通用的东西，大家在做选型时有利用开源的，也有自己造轮子的，乃至有直接用 MySQL 或 Redis 做行列步队的，关键看是否知足你的需求.

选择得当的中间件须要考虑多个成分，包括但不限于：

须要处理的数量和频率的大小和格式可用性和容错性哀求数据安全性和加密需求扩展性和灵巧性哀求开拓措辞和技能栈的兼容性 常见的中间件包括RocketMQ、Kafka、 RabbitMQ、Kafka、ActiveMQ、Redis、NATS 等，每种中间件都有其特点和适用场景。

如果须要处理大量的并且须要高吞吐量和低延迟，可以考虑利用 Kafka。
如果须要实时处理并且须要高可用性和容错性，可以考虑利用 RabbitMQ。
如果须要处理轻量级的，并且须要高性能和低延迟，可以考虑利用 Redis。

在选择中间件时，须要根据详细的业务需求和技能栈进行综合考虑，选择最得当的中间件。

目前建议 kafka + RocketMQ

选择和搭建高性能的关系数据库

关系数据库分为两种，一种是传统关系数据，如 Oracle，MySQL，Maria，DB2，PostgreSQL 等等，另一种是 NewSQL，即至少要知足以下五点的新型关系数据库：

完全地支持 SQL，支持 JOIN / GROUP BY /子查询等繁芜 SQL 查询。
支持传统数据标配的 ACID 事务，支持强隔离级别。
具有弹性伸缩的能力，扩容缩容对付业务层完备透明。
真正的高可用，异地多活、故障规复的过程不须要人为的接入，系统能够自动地容灾和进行强同等的数据规复。
具备一定的大数据剖析能力。

传统关系数据库用得最多的是 MySQL，成熟，稳定，一些基本的需求都能知足，在一定数据量级之前基本单机传统数据库都可以搞定，而且现在较多的开源系统都是基于 MySQL，开箱即用，再加上主从同步和前端缓存，百万 pv 的运用都可以搞定了。

不过 CentOS 7 已经放弃了 MySQL，而改利用 MariaDB。
MariaDB 数据库管理系统是 MySQ L的一个分支，紧张由开源社区在掩护，采取 GPL 授权容许。
开拓这个分支的缘故原由之一是：甲骨文公司收购了 MySQL 后，有将 MySQL 闭源的潜在风险，因此社区采取分支的办法来避开这个风险。

在 Google 发布了 F1: A Distributed SQL Database That Scales 和 Spanner: Google’s Globally-Distributed Databasa 之后，业界开始盛行起 NewSQL。
于是有了 CockroachDB，以及PingCAP的 TiDB。

海内已经有比较多的公司利用 TiDB，之前在创业公司时在大数据剖析时已经开始运用 TiDB，当时运用的紧张缘故原由是 MySQL 要利用分库分表，逻辑开拓比较繁芜，扩展性不足。

选择和搭建高性能的NoSQL

NoSQL 顾名思义便是 Not-Only SQL，也有人说是 No – SQL，个人倾向于 Not-Only SQL，它并不是用来替代关系库，而是作为关系型数据库的补充而存在。

常见 NoSQL 有4个类型：

键值，适用于内容缓存，适宜稠浊事情负载并发高扩展哀求大的数据集，其优点是大略，查询速率快，缺陷是短缺构造化数据，常见的有 Redis，Memcache，BerkeleyDB 和 Voldemort 等等；列式，以列簇式存储，将同一列数据存在一起，常见于分布式的文件系统，个中以 Hbase，Cassandra 为代表。
Cassandra 多用于写多读少的场景，海内用得比较多的有 360，大概 1500 台机器的集群，国外大规模利用的公司比较多，如 eBay，Instagram，Apple 和沃尔玛等等；文档，数据存储方案非常适用承载大量不干系且构造差别很大的繁芜信息。
性能介于 kv 和关系数据库之间，它的灵感来于 lotus notes，常见的有 MongoDB，CouchDB 等等；图形，图形数据库善于处理任何涉及关系的状况。
社交网络，推举系统等。
专注于构建关系图谱，须要对全体图做打算才能得出结果，不随意马虎做分布式的集群方案，常见的有 Neo4J，InfoGrid 等。

除了以上4种类型，还有一些特种的数据库，如工具数据库，XML 数据库，这些都有针对性对某些存储类型做了优化的数据库。

在实际运用处景中，何时利用关系数据库，何时利用 NoSQL，利用哪种类型的数据库，这是我们在做架构选型时一个非常主要的考量，乃至会影响全体架构的方案。

CICD发布系统/支配系统的架构

软件生产的层面看，代码到终极做事的范例流程如图2 所示：

图2 流程图

从上图中可以看出，从开拓职员写下代码到做事终极用户是一个漫上进程，整体可以分成三个阶段：

从代码（Code）到制品库（Artifact）：这个阶段紧张对开拓职员的代码做持续构建，并把构建产生的制品集中管理，是为支配系统准备输入内容的阶段。
从制品到可运行做事：这个阶段紧张完成制品支配到指定环境，是支配系统的最基本事情内容。
从开拓环境到最终生产环境：这个阶段紧张完成一次变更在不同环境的迁移，是支配系统上线终极做事的核心能力。

发布系统集成了制品管理，发布流程，权限掌握，线上环境版本变更，灰度发布，线上做事回滚等几方面的内容，是开拓职员事情结晶终极呈现的主要通道。

CI/CD 发布系统/支配系统的架构常日包括以下组件：

源代码管理系统：例如 Git、SVN 等，用于管理代码库。
持续集成工具：例如 Jenkins、GitLab CI、Travis CI 等，用于自动化构建、测试和打包运用程序。
制品仓库：例如 Docker Hub、Harbor、Aliyun Container Registry 等，用于存储运用程序的镜像。
支配工具：例如 Kubernetes、Docker Swarm、Mesos 等，用于自动化支配运用程序。

这些组件可以根据实际需求进行选择和组合，形成一个完全的 CI/CD 发布系统/支配系统。

个中，持续集成工具和支配工具是核心组件，它们卖力自动化构建、测试、打包和支配运用程序，从而实现快速、可靠、可重复的软件发布流程。

项目初期可以集成 Jenkins + Gitlab + Harbor，以上方案基本包括制品管理，发布流程，权限掌握，线上环境版本变更，灰度发布（须要自己实现），线上做事回滚等功能。

代码管理工具选型

代码是项目的命脉之一，代码管理很主要，常见的考量点包括两块：

安全和权限管理，将代码放到内网并且对付关系公司命脉的核心代码做严格的代码掌握和机器的物理隔离；代码管理工具，Git 作为代码管理的不二之选，你值得拥有。

GitLab 是当今最火的开源 Git 托管做事端，没有之一，虽然有企业版，但是其社区版基本能知足我们大部分需求，结合 Gerrit 做 Code review，基本就完美了。

当然 GitLab 也有代码比拟，但没 Gerrit 直不雅观。

Gerrit 比 GitLab 供应了更好的代码检讨界面与主线管理体验，更适宜在对代码质量有高哀求的文化下利用。

持续集成工具选型

持续集成简称 CI（continuous integration），是一种软件开拓实践，即团队开拓成员常常集成他们的事情，每天可能会发生多次集成。

每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地创造集成缺点。

持续集成为研发流程供应了代码分支管理/比对、编译、检讨、发布物输出等根本事情，为测试的覆盖率版本编译、天生等供应统一支持。

业界免费的持续集成工具中系统我们有如下一些选择：

Jenkins：Java 写的有强大的插件机制，MIT 协议开源 （免费，定制化程度高，它可以在多台机器上进行分布式地构建和负载测试）。
Jenkins 可以算是无所不能，基本没有 Jenkins 做不了的，无论从小型团队到大型团队 Jenkins 都可以搞定。
不过如果要大规模利用，还是须要有人力来学习和掩护。
TeamCity：TeamCity 与 Jenkins 比较利用更加友好，也是一个高度可定制化的平台。
但是用的人多了，TeamCity就要收费了。
Strider：Strider 是一个开源的持续集成和支配平台，利用 Node.js 实现，存储利用的是 MongoDB，BSD 容许证，观点上类似 Travis 和Jenkins。
GitLab CI：从GitLab 8.0开始，GitLab CI 就已经集成在 GitLab，我们只要在项目中添加一个 .gitlab-ci.yml 文件，然后添加一个 Runner，即可进行持续集成。
并且 GitLab 与 Docker 有着非常好的相互协作的能力。
Travis：Travis 和 GitHub 强关联；闭源代码利用 SaaS 还需考虑安全问题；不可定制；开源项目免费，其它收费。
Go：Go 是 ThoughtWorks 公司最新的 Cruise Control 的化身。
除了 ThoughtWorks 供应的商业支持，Go 是免费的。
它适用于 Windows，Mac 和各种 Linux 发行版。

自动化测试平台的架构

接下来，便是自动化测试平台的搭建。

搭建自动化测试平台须要考虑以下几个方面：

选择得当的测试框架和工具：可以选择一些盛行的测试框架和工具，如Selenium、Appium、JMeter等，根据须要选择适宜自己的工具。
搭建测试环境：须要搭建测试环境，包括测试做事器、测试数据库、测试数据等。
可以利用虚拟机或者容器来搭建测试环境，以便进行测试。
编写测试用例：须要编写测试用例，测试用例该当覆盖系统的各个功能点，以便创造潜在的问题。
集成测试工具和测试用例：将测试工具和测试用例集成到自动化测试平台中，以便进行自动化测试。
运行测试用例：编写好测试用例后，须要运行测试用例，网络测试结果，并天生测试报告。
定期掩护和更新：自动化测试平台须要定期掩护和更新，以担保测试环境的稳定性和测试用例的有效性。

以上是搭建自动化测试平台的一样平常步骤，详细实现办法还须要根据实际情形进行调度。

可以结合 SpringBoot + TestNG 测试框架，搭建自己的 自动化测试平台

提示，不用自己从0到1 去搭建自动化测试平台，可以基于开源的自动化测试平台进行改造。

下面的两个测试平台，就是非常好的改造项目：

接口自动化测试框架（java httpClient + testNg）ChenSen5/api_autotest (https://github.com/ChenSen5/api_autotest)基于SpringBoot的高效模板化自动化测试框架jinganglong123/jg-api-autotest (https://github.com/jinganglong123/jg-api-autotest)

360度全方位监控和掩护的架构

360度全方位监控和掩护的架构包括

日志系统监控系统

日志系统

日志系统一样平常包括打日志，采集，中转，网络，存储，剖析，呈现，搜索还有分发等。

一些分外的如染色，全链条跟踪或者监控都可能须要依赖于日志系统实现。

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

对付常规日志系统ELK能知足大部分的需求，ELK 包括如下组件：

ElasticSearch 是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动创造，索引自动分片，索引副本机制，RESTful 风格接口，多数据源，自动搜索负载等。

Logstash 是一个完备开源的工具，它可以对你的日志进行网络、剖析，并将其存储供往后利用。
Kibana 是一个开源和免费的工具，它可以为 Logstash 和 ElasticSearch 供应的日志剖析友好的 Web 界面，可以帮助汇总、剖析和搜索主要数据日志。

Filebeat 已经完备替代了 Logstash-Forwarder 成为新一代的日志采集器，同时鉴于它轻量、安全等特点，越来越多人开始利用它。

由于免费的 ELK 没有任何安全机制，以是这里利用了 Nginx 作反向代理，避免用户直接访问 Kibana 做事器。

加上配置 Nginx 实现大略的用户认证，一定程度长进步安全性。

其余，Nginx 本身具有负载均衡的浸染，能够提高系统访问性能。

ELK 架构如图3 所示：

图3 ELK 流程图

对付有实时打算的需求，可以利用 Flume + Kafka + Storm + MySQL 方案，一 般架构如图4 所示：

图4 实时剖析系统架构图

个中：

Flume 是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的日志网络系统，支持在日志系统中定制各种数据发送方，用于网络数据；同时，Flume 供应对数据进行大略处理，并写到各种数据接管方（可定制）的能力。
Kafka 是由 Apache 软件基金会开拓的一个开源流处理平台，由 Scala 和 Java 编写。
实在质上是一个“按照分布式事务日志架构的大规模发布/订阅行列步队”，它以可水平扩展和高吞吐率而被广泛利用。

Kafka 追求的是高吞吐量、高负载，Flume 追求的是数据的多样性，二者结合起来切实其实完美。

监控系统

监控系统只包含与后台干系的，这里紧张是两块，一个是操作系统层的监控，比如机器负载，IO，网络流量，CPU，内存等操作系统指标的监控。

另一个是做事质量和业务质量的监控，比如做事的可用性，成功率，失落败率，容量，QPS 等等。

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

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

这里有一个有趣的分布，如图5 所示。

图5 监控系统分布

亚洲区域利用 Zabbix 较多，而美洲和欧洲，以及澳大利亚利用 Prometheus 居多，换句话说，英文国家地区（发达国家？）利用 Prometheus 较多。

Prometheus 是由 SoundCloud 开拓的开源监控报警系统和时序列数据库（TSDB）。

Prometheus 利用 Go 措辞开拓，是 Google BorgMon 监控系统的开源版本。

相对付其它监控系统利用的 push 数据的办法，Prometheus 利用的是 pull 的办法，其架构如图6 所示：

图6 Prometheus 架构图

如上图所示，Prometheus 包含的紧张组件如下：

Prometheus Server：紧张卖力数据采集和存储，供应 PromQL 查询措辞的支持。
Server：通过配置文件、文本文件、ZooKeeper、Consul、DNS SRV Lookup 等办法指定抓取目标。

根据这些目标会，Server 定时去抓取 metrics 数据，每个抓取目标须要暴露一个 http 做事的接口给它定时抓取。

客户端 SDK：官方供应的客户端类库有 Go、Java、Scala、Python、Ruby，其他还有很多第三方开拓的类库，支持 Nodejs、PHP、Erlang 等。
Push Gateway：支持临时性 Job 主动推送指标的中间网关。
Exporter Exporter：是 Prometheus 的一类数据采集组件的总称。
它卖力从目标处搜集数据，并将其转化为 Prometheus 支持的格式。

与传统的数据采集组件不同的是，它并不向中心做事器发送数据，而是等待中心做事器主动前来抓取。

Prometheus：供应多种类型的 Exporter 用于采集各种不同做事的运行状态。
目前支持的有数据库、硬件、中间件、存储系统、HTTP 做事器、JMX 等。
Alertmanager：是一个单独的做事，可以支持 Prometheus 的查询语句，供应十分灵巧的报警办法。
Prometheus HTTP API 的查询办法，自定义所须要的输出。
Grafana：是一套开源的剖析监视平台，支持 Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch 等数据源，其 UI 非常俊秀且高度定制化。

创业公司选择 Prometheus + Grafana 的方案，再加上统一的做事框架（如 gRPC），可以知足大部分中小团队的监控需求。

生产环境高并发高吞吐负载均衡支配架构

高并发高吞吐负载均衡链路架构，包括：

DNS的选型和利用设计LB（负载均衡）的选型和利用设计CDN的选型和利用设计

DNS的选型和利用设计

DNS 是一个很通用的做事，创业公司基本上选择一个得当的云厂商就行了，海内紧张是两家：

阿里万网：阿里 2014 年收购了万网，整合了其域名做事，终极形成了现在的阿里万网，个中就包含 DNS 这块的做事；

腾讯 DNSPod：腾讯 2012 年以 4000 万收购 DNSPod 100% 股份，紧张供应域名解析和一些防护功能；

如果你的业务是在海内，紧张便是这两家，选 一个就好，像今日头条这样的企业用的也是 DNSPod 的做事，除非一些分外的缘故原由才须要自建，比如一些 CDN 厂商，或者对区域有分外限定的。

要实惠一点用阿里最便宜的根本版就好了，要成功率高一些，还是用 DNSPod 的贵的那种。

在国外还是选择亚马逊吧，阿里的 DNS 做事只有在日本和美国有节点，东南亚最近才开始部点， DNSPod 也只有美国和日本，像一些出海的企业，其选择的云做事基本都是亚马逊。

如果是线上产品，DNS 强烈建议用付费版，阿里的那几十块钱的付费版基本可以知足需求。
如果还须要一些按省份或按区域调试的逻辑，则须要加钱，一年也就几百块，省钱省力。

如果是国外，优先选择亚马逊，如果须要国内外互通并且有自己的 APP 的话，建议还是自己实现一些容灾逻辑或者智能调度，由于没有一个现成的 DNS 做事能同时较好的知足国内外场景，或者用多个域名，不同的域名走不同的 DNS 。

LB（负载均衡）的选型和利用设计

LB（负载均衡）是一个通用做事，一样平常云厂商的 LB 做事基本都会如下功能：

支持四层协议要求（包括 TCP、UDP 协议）；支持七层协议要求（包括 HTTP、HTTPS 协议）；集中化的证书管理系统支持 HTTPS 协议；康健检讨；

如果你线上的做事机器都是用的云做事，并且是在同一个云做事商的话，可以直策应用云做事商供应的 LB 做事，如阿里云的 SLB，腾讯云的 CLB，亚马逊的 ELB 等等。
如果是自建机房基本都是 LVS + Nginx。

CDN的选型和利用设计

CDN 现在已经是一个很红很红的市场，基本上只能挣一些辛劳钱，都是贴着本钱在卖。
海内以网宿为龙头，他们家霸占全体海内市场份额的 40% 以上，后面便是腾讯，阿里。
网宿有很大一部分是由于直播的兴起而崛起。

国外，Amazon 和 Akamai合起来占频年夜概在 50%，曾经的国际市场老大 Akamai 拥有环球超一半的份额，在 Amazon CDN入局后，份额跌去了将近 20%，浩瀚中小企业都转向后者，Akamai 也是无能为力。

海内出海的 CDN 厂商，更多的是为海内的出海企业做事，三家大一点的 CDN 做事商里面也就网宿的节点多一些，但是也多不了多少。
阿里和腾讯还处于前期阶段，仅少部分国家有节点。

末了

好的架构不是一挥而就的，而是演化出来的。
对付一个问题，架构师须要做出精确的判断，而这个“精确”与否，在不同的场景下，也是不同的，也便是说答案是开放的。
那么提高自己的技能能力、认知能力，就相称主要了。
这就哀求我们不断地学习，保持对技能的敏锐，才能做出精确的选择。

路漫漫其修远兮，架构求索无止尽也。

标签：须要做事