备案后可以修改网站吗,网站开发和商城的科目,万户网站协作管理系统,wordpress宠物后台架构的11个维度 架构1#xff1a;团队协助基础工具链的选型和培训架构2#xff1a;搭建微服务开发基础设施架构3#xff1a;选择合适的RPC框架架构4#xff1a;选择和搭建高可用的注册中心架构5#xff1a;选择和搭建高可用的配置中心架构6#xff1a;选择和搭建高性… 后台架构的11个维度 架构1团队协助基础工具链的选型和培训架构2搭建微服务开发基础设施架构3选择合适的RPC框架架构4选择和搭建高可用的注册中心架构5选择和搭建高可用的配置中心架构6选择和搭建高性能的缓存中间件架构7选择和搭建高性能的消息中间件架构8选择和搭建高性能的关系数据库架构9CICD发布系统/部署系统的架构架构10360度全方位监控和维护的架构架构11生产环境高并发高吞吐负载均衡部署架构 整个后台技术架构主要包括 4 个层面的内容 语言用了哪些开发语言如C/Java/Go/PHP/Python/Ruby 等等组件用了哪些组件如MQ 组件数据库组件等等流程怎样的流程和规范如开发流程项目流程发布流程监控告警流程代码规范等等系统系统化建设上面的流程需要有系统来保证如规范发布流程的发布系统代码管理系统等等 团队协助基础工具链的选型和培训 团队协助基础工具链 主要是三大管理 项目管理任务管理问题管理 项目管理软件是整个业务的需求问题流程等等的集中地大家的跨部门沟通协同大多依赖于项目管理工具 Jira用 Java 开发的有用户故事task 拆分燃尽图等等可以做项目管理也可以应用于跨部门沟通场景较强大Redmine用 Ruby 开发的有较多的插件可以使用能自定义字段集成了项目管理Bug 问题跟踪WIKI 等功能不过好多插件 N 年没有更新了Phabricator用 PHP 开发的Facebook 之前的内部工具开发这工具的哥们离职后自己搞了一个公司专门做这个软件集成了代码托管 Code Review任务管理文档管理问题跟踪等功能强烈推荐较敏捷的团队使用 搭建微服务开发基础设施 搭建微服务开发基础设施需要考虑多个方面包括但不限于以下几点 选择合适的微服务框架和技术栈目前比较流行的微服务框架有 Spring Cloud、Go-Micro、gRPC等选择适合自己团队技术栈的框架非常重要选择合适的RPC框架构建基础设施包括但不限于服务注册与发现、负载均衡、API 网关、分布式配置中心、分布式锁、消息队列等安全包括但不限于服务间通信的加密、访问控制、身份认证等。 在搭建微服务开发基础设施之前需要对自己的业务场景进行分析和规划确定需要哪些基础设施和技术栈然后再逐步实现。同时需要注重可扩展性和可维护性以便在业务发展过程中能够快速适应变化。 选择合适的微服务框架和技术栈 选择合适的微服务框架和技术栈需要考虑多个因素包括以下几个方面 业务需求不同的业务需求需要不同的技术栈和框架来支持。比如如果需要高并发和高可用性可以选择使用 Go 语言和 Kubernetes 等技术来构建微服务。开发团队技能选择的技术栈和框架应该符合开发团队的技能水平以便开发人员能够快速上手并高效开发社区支持选择流行的技术栈和框架可以获得更好的社区支持能够更快地解决问题和获得更新的功能性能和稳定性选择的技术栈和框架应该具有良好的性能和稳定性以便能够支持高负载和长时间运行 常见的微服务框架和技术栈包括 Spring Cloud适用于 Java 开发团队具有丰富的功能和社区支持Go Micro适用于 Go 开发团队具有高性能和简单易用的特点。Node.js Express适用于 JavaScript 开发团队具有轻量级和快速开发的特点。Kubernetes适用于需要高可用性和弹性的微服务架构可以支持多种编程语言和框架。Istio适用于需要服务网格功能的微服务架构可以提供流量管理、安全性和可观察性等功能 建议选用 SpringCloud Alibaba Dubbo RPC Dubbo-Go两个原因 高性能 性能测试案例中 Dubbo比Feign性能 强10倍兼顾团队技术栈 可以跨Go 和Java 多语言微服务架构Java技术栈的可以基于 Java开发业务微服务这块侧重业务开发,Go 技术栈的可以基于 Go 开发高性能的 技术微服务这块侧重技术开发和性能优化功能和性能兼顾 Java侧重功能的快速开发 Go侧重性能的快速提升。 选择合适的RPC框架 维基百科对 RPC 的定义是远程过程调用Remote Procedure CallRPC是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序而程序员无需额外地为这个交互作用编程通俗来讲一个完整的 RPC 调用过程就是 Server 端实现了一个函数客户端使用 RPC 框架提供的接口调用这个函数的实现并获取返回值的过程业界 RPC 框架大致分为两大流派一种侧重跨语言调用另一种是偏重服务治理跨语言调用型RPC 跨语言调用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。这类 RPC 框架侧重于服务的跨语言调用能够支持大部分的语言进行语言无关的调用非常适合多语言调用场景。但这类框架没有服务发现相关机制实际使用时需要代理层进行请求转发和负载均衡策略控制其中gRPC 是 Google 开发的高性能、通用的开源 RPC 框架其由 Google 主要面向移动应用开发并基于 HTTP/2 协议标准而设计基于 ProtoBufProtocol Buffers序列化协议开发且支持众多开发语言。本身它不是分布式的所以要实现框架的功能需要进一步的开发。HproseHigh Performance Remote Object Service Engine是一个 MIT 开源许可的新型轻量级跨语言跨平台的面向对象的高性能远程动态通讯中间件。 冶理型 RPC 服务治理型的 RPC 框架的特点是功能丰富提供高性能的远程调用、服务发现及服务治理能力适用于大型服务的服务解耦及服务治理对于特定语言(Java)的项目可以实现透明化接入。缺点是语言耦合度较高跨语言支持难度较大国内常见的冶理型 RPC 框架如下 DubboDubbo 是阿里巴巴公司开源的一个 Java 高性能优秀的服务框架使得应用可通过高性能的RPC 实现服务的输出和输入功能可以和 Spring 框架无缝集成。当年在淘宝内部Dubbo 由于跟淘宝另一个类似的框架 HSF 有竞争关系导致 Dubbo 团队解散最近又活过来了有专职同学投入。DubboXDubboX 是由当当在基于 Dubbo 框架扩展的一个 RPC 框架支持 REST 风格的远程调用、Kryo/FST 序列化增加了一些新的feature。MotanMotan 是新浪微博开源的一个 Java 框架。它诞生的比较晚起于 2013 年2016 年 5 月开源。Motan 在微博平台中已经广泛应用每天为数百个服务完成近千亿次的调用rpcxrpcx 是一个类似阿里巴巴 Dubbo 和微博 Motan 的分布式的 RPC 服务框架基于 Golang net/rpc 实现。但是 rpcx 基本只有一个人在维护没有完善的社区使用前要慎重 建议选用Dubbo两个原因 高性能 性能测试案例中 Dubbo比Feign性能 强10倍跨语言 可以跨Go 和Java 进行 双语言的 RPC调用从而实现 多语言微服务架构。 选择和搭建高可用的注册中心 名字发现和服务发现分为两种模式一个是客户端发现模式一种是服务端发现模式。框架中常用的服务发现是客户端发现模式所谓服务端发现模式是指客户端通过一个负载均衡器向服务发送请求负载均衡器查询服务注册表并把请求路由到一台可用的服务实例上。现在常用的负载均衡器都是此类模式常用于微服务中所有的名字发现和服务发现都要依赖于一个可用性非常高的服务注册表业界常用的服务注册表有如下三个 etcd一个高可用、分布式、一致性、key-value 方式的存储被用在分享配置和服务发现中。两个著名的项目使用了它Kubernetes 和 Cloud FoundryConsul一个发现和配置服务的工具为客户端注册和发现服务提供了APIConsul还可以通过执行健康检查决定服务的可用性Apache ZooKeeper是一个广泛使用、高性能的针对分布式应用的协调服务。Apache ZooKeeper 本来是 Hadoop 的子工程现在已经是顶级工程了除此之外还有eureka, nacos等大家可以根据相关的组件特性选择适合自己的组件。 选择和搭建高可用的注册中心需要考虑以下几个方面 功能需求选择注册中心时需要根据自己的业务需求来选择比如服务发现、负载均衡、配置管理等。性能要求注册中心需要具备高性能能够支持高并发、高吞吐量的请求可用性要求注册中心需要具备高可用性能够保证24小时不间断运行避免因为单点故障导致整个系统不可用安全要求注册中心需要具备一定的安全性能够保证数据的机密性和完整性避免数据泄露和篡改 常见的注册中心有 ZooKeeper、Etcd、Consul 等它们都具备高可用性和安全性并且都支持服务发现和配置管理等功能。其中ZooKeeper 是最早的分布式协调服务具备成熟的生态系统和广泛的应用场景Etcd 是 CoreOS 推出的开源分布式键值存储系统具备高可用性和一致性保证Consul 是HashiCorp 推出的服务发现和配置管理工具具备易用性和可扩展性在搭建高可用的注册中心时需要采用集群部署的方式避免单点故障。同时为了保证数据的安全性可以启用 SSL/TLS 加密功能并采用访问控制机制来限制访问权限 选择和搭建统一配置中心 随着程序功能的日益复杂程序的配置日益增多各种功能的开关、降级开关灰度开关参数的配置、服务器的地址、数据库配置等等除此之外对后台程序配置的要求也越来越高配置修改后实时生效灰度发布分环境、分用户分集群管理配置完善的权限、审核机制等等在这样的大环境下传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求需要统一的、基础的配置系统统一配置系统是指在一个大型系统中将所有的配置信息集中管理以便于对系统进行管理和维护。常见的统一配置系统架构包括以下几个组件 配置中心用于存储和管理所有的配置信息提供配置查询、修改、删除等功能配置客户端用于从配置中心获取配置信息并将其应用到系统中配置发布工具用于将配置信息发布到配置中心以便于配置客户端获取。配置管理工具用于对配置信息进行管理和维护包括配置的新增、修改、删除等操作配置监控工具用于监控配置信息的变化及时发现并处理配置信息的异常情况 在实际应用中可以选择使用开源的配置中心工具如 ZooKeeper、Etcd、Consul 、Nacos、Apollo等也可以自己开发一套配置中心系统同时还需要根据实际情况选择合适的配置客户端和配置发布工具。在配置管理和监控方面可以使用一些开源的工具或者自己开发一套系统。总之统一配置系统的架构需要根据实际需求进行设计和选择 选择和搭建高性能的缓存中间件 选择和搭建高性能的缓存中间件需要考虑多个因素包括性能、可靠性、可扩展性、易用性等。以下是一些常见的高性能缓存中间件 RedisRedis 是一个开源的高性能缓存和键值存储系统支持多种数据结构包括字符串、哈希、列表、集合和有序集合等。Redis 通过将数据存储在内存中来提高性能同时支持数据持久化和集群模式MemcachedMemcached 是一个开源的高性能分布式内存对象缓存系统可以缓存任何可序列化的数据如数据库查询结果、API 响应等。Memcached 可以通过多个节点组成的集群来提高可扩展性和可靠性HazelcastHazelcast 是一个开源的分布式内存数据网格系统支持缓存、分布式数据结构和分布式计算等功能。Hazelcast 可以通过多个节点组成的集群来提高可扩展性和可靠性CouchbaseCouchbase 是一个开源的分布式 NoSQL 数据库和缓存系统可以缓存任何类型的数据包括 JSON 文档、键值对和二进制数据等。Couchbase 支持多个节点组成的集群和数据持久化等功能 在搭建高性能缓存中间件时需要考虑以下几个方面 硬件配置缓存中间件需要占用大量内存因此需要配置足够的内存和处理器资源部署架构需要考虑缓存中间件的部署架构如单节点、主从复制、集群等数据持久化需要考虑数据持久化的方式如内存快照、AOF 日志、RDB 文件等安全性需要考虑缓存中间件的安全性如访问控制、数据加密等监控和管理需要考虑缓存中间件的监控和管理如性能监控、故障诊断等 建议是 高可用的redis cluster 要特别注意的是 redis 关系到系统的 高可用 很容易出生产事故如果 redis 出现bigkey在 高并发场景下 很容易出现 系统瘫痪 严重影响系统的可用性为大key申请专用的单机节点走主从模式 选择和搭建高性能的消息中间件 消息中间件在后台系统中是必不可少的一个组件一般我们会在以下场景中使用消息中间件 异步处理异步处理是使用消息中间件的一个主要原因在工作中最常见的异步场景有用户注册成功后需要发送注册成功邮件、缓存过期时先返回老的数据然后异步更新缓存、异步写日志等等通过异步处理可以减少主流程的等待响应时间让非主流程或者非重要业务通过消息中间件做集中的异步处理系统解耦比如在电商系统中当用户成功支付完成订单后需要将支付结果给通知ERP系统、发票系统、WMS、推荐系统、搜索系统、风控系统等进行业务处理这些业务处理不需要实时处理、不需要强一致只需要最终一致性即可因此可以通过消息中间件进行系统解耦。通过这种系统解耦还可以应对未来不明确的系统需求削峰填谷当系统遇到大流量时监控图上会看到一个一个的山峰样的流量图通过使用消息中间件将大流量的请求放入队列通过消费者程序将队列中的处理请求慢慢消化达到消峰填谷的效果。最典型的场景是秒杀系统在电商的秒杀系统中下单服务往往会是系统的瓶颈因为下单需要对库存等做数据库操作需要保证强一致性此时使用消息中间件进行下单排队和流控让下单服务慢慢把队列中的单处理完保护下单服务以达到削峰填谷的作用 业界消息中间件是一个非常通用的东西大家在做选型时有使用开源的也有自己造轮子的甚至有直接用 MySQL 或 Redis 做队列的关键看是否满足你的需求选择合适的消息中间件需要考虑多个因素包括但不限于 需要处理的消息数量和频率消息的大小和格式可用性和容错性要求数据安全性和加密需求扩展性和灵活性要求开发语言和技术栈的兼容性 常见的消息中间件包括RocketMQ、Kafka、 RabbitMQ、Kafka、ActiveMQ、Redis、NATS 等每种中间件都有其特点和适用场景如果需要处理大量的消息并且需要高吞吐量和低延迟可以考虑使用 Kafka。如果需要实时处理消息并且需要高可用性和容错性可以考虑使用 RabbitMQ。如果需要处理轻量级的消息并且需要高性能和低延迟可以考虑使用 Redis。 选择和搭建高性能的关系数据库 关系数据库分为两种一种是传统关系数据如 OracleMySQLMariaDB2PostgreSQL 等等另一种是 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 GloballyDistributed Databasa 之后业界开始流行起 NewSQL。于是有了 CockroachDB于是有了奇叔公司的 TiDB 选择和搭建高性能的NoSQL NoSQL 顾名思义就是 Not-Only SQL也有人说是 No – SQL个人偏向于 Not-Only SQL它并不是用来替代关系库而是作为关系型数据库的补充而存在常见 NoSQL 有4个类型 键值适用于内容缓存适合混合工作负载并发高扩展要求大的数据集其优点是简单查询速度快缺点是缺少结构化数据常见的有 RedisMemcacheBerkeleyDB 和 Voldemort 等等列式以列簇式存储将同一列数据存在一起常见于分布式的文件系统其中以 HbaseCassandra 为代表。Cassandra 多用于写多读少的场景国内用得比较多的有 360大概 1500台机器的集群国外大规模使用的公司比较多如 eBayInstagramApple 和沃尔玛等等文档数据存储方案非常适用承载大量不相关且结构差别很大的复杂信息。性能介于 kv 和关系数据库之间它的灵感来于 lotus notes常见的有 MongoDBCouchDB 等等图形图形数据库擅长处理任何涉及关系的状况。社交网络推荐系统等。专注于构建关系图谱需要对整个图做计算才能得出结果不容易做分布式的集群方案常见的有 Neo4JInfoGrid等 除了以上4种类型还有一些特种的数据库如对象数据库XML 数据库这些都有针对性对某些存储类型做了优化的数据库。在实际应用场景中何时使用关系数据库何时使用 NoSQL使用哪种类型的数据库这是我们在做架构选型时一个非常重要的考量甚至会影响整个架构的方案。 CICD发布系统/部署系统的架构 软件生产的层面看代码到最终服务的典型流程如图 所示 从上图中可以看出从开发人员写下代码到服务最终用户是一个漫长过程整体可以分成三个阶段 从代码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 提供了更好的代码检查界面与主线管理体验更适合在对代码质量有高要求的文化下使用。 持续集成工具选型 持续集成简称 CIcontinuous integration是一种软件开发实践即团队开发成员经常集成他们的工作每天可能会发生多次集成每次集成都通过自动化的构建包括编译发布自动化测试来验证从而尽早地发现集成错误持续集成为研发流程提供了代码分支管理/比对、编译、检查、发布物输出等基础工作为测试的覆盖率版本编译、生成等提供统一支持业界免费的持续集成工具中系统我们有如下一些选择 JenkinsJava 写的有强大的插件机制MIT 协议开源 免费定制化程度高它可以在多台机器上进行分布式地构建和负载测试。Jenkins 可以算是无所不能基本没有 Jenkins 做不了的无论从小型团队到大型团队 Jenkins 都可以搞定。不过如果要大规模使用还是需要有人力来学习和维护。TeamCityTeamCity 与 Jenkins 相比使用更加友好也是一个高度可定制化的平台。但是用的人多了TeamCity就要收费了StriderStrider 是一个开源的持续集成和部署平台使用 Node.js 实现存储使用的是 MongoDBBSD 许可证概念上类似 Travis 和JenkinsGitLab CI从GitLab 8.0开始GitLab CI 就已经集成在 GitLab我们只要在项目中添加一个 .gitlab-ci.yml 文件然后添加一个 Runner即可进行持续集成。并且 GitLab 与 Docker 有着非常好的相互协作的能力。TravisTravis 和 GitHub 强关联闭源代码使用 SaaS 还需考虑安全问题不可定制开源项目免费其它收费。GoGo 是 ThoughtWorks 公司最新的 Cruise Control 的化身。除了 ThoughtWorks 提供的商业支持Go 是免费的。它适用于 WindowsMac 和各种 Linux 发行版 自动化测试平台的架构 搭建自动化测试平台需要考虑以下几个方面 选择合适的测试框架和工具可以选择一些流行的测试框架和工具如Selenium、Appium、JMeter等根据需要选择适合自己的工具搭建测试环境需要搭建测试环境包括测试服务器、测试数据库、测试数据等。可以使用虚拟机或者容器来搭建测试环境以便进行测试。编写测试用例需要编写测试用例测试用例应该覆盖系统的各个功能点以便发现潜在的问题集成测试工具和测试用例将测试工具和测试用例集成到自动化测试平台中以便进行自动化测试。运行测试用例编写好测试用例后需要运行测试用例收集测试结果并生成测试报告。定期维护和更新自动化测试平台需要定期维护和更新以保证测试环境的稳定性和测试用例的有效性 可以结合 SpringBoot TestNG 测试框架搭建自己的 自动化测试平台 TestNG 是一个开源自动化测试框架;TestNG 灵感来自 JUnit 和 NUnit但引入了一些新的功能使其功能更强大使用更方便。TestNG表示下一代(Next Generation的首字母)。TestNG类似于 JUnit (特别是 JUnit 4)但它不是JUnit框架的扩展。它的目的是优于 JUnit 尤其是在用于测试集成多类时。TestNG消除了大部分的旧框架的限制使开发人员能够编写更加灵活和强大的测试。 因为它在很大程度上借鉴了Java注解( JDK5.0引入的)来定义测试它也可以显示如何使用这个新功能在真实的 Java 语言生产环境中 下面的两个 测试平台就是非常好的 改造项目 接口自动化测试框架java httpClient testNgChenSen5/api_autotest: 接口自动化测试框架java httpClient testNg (github.com)基于SpringBoot的高效模板化自动化测试框架 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 本身具有负载均衡的作用能够提高系统访问性能。 对于有实时计算的需求可以使用 Flume Kafka Storm MySQL 方案一 般架构如图所示 Flume 是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的日志收集系统支持在日志系统中定制各类数据发送方用于收集数据同时Flume 提供对数据进行简单处理并写到各种数据接受方可定制的能力。 Kafka 是由 Apache 软件基金会开发的一个开源流处理平台由 Scala 和 Java 编写。其本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”它以可水平扩展和高吞吐率而被广泛使用。 Kafka 追求的是高吞吐量、高负载Flume 追求的是数据的多样性二者结合起来简直完美。 监控系统 监控系统只包含与后台相关的这里主要是两块一个是操作系统层的监控比如机器负载IO网络流量CPU内存等操作系统指标的监控 另一个是服务质量和业务质量的监控比如服务的可用性成功率失败率容量QPS 等等 常见业务的监控系统先有操作系统层面的监控这部分较成熟然后扩展出其它监控如 Zabbix小米的 Open-Falcon也有一出来就是两者都支持的如 Prometheus 如果对业务监控要求比较高一些在创业选型中建议可以优先考虑 Prometheus。 Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库TSDB。 Prometheus 使用 Go 语言开发是 Google BorgMon 监控系统的开源版本。 相对于其它监控系统使用的 push 数据的方式Prometheus 使用的是 pull 的方式 如上图所示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 是 Prometheus 的一类数据采集组件的总称。它负责从目标处搜集数据并将其转化为 Prometheus 支持的格式。与传统的数据采集组件不同的是它并不向中央服务器发送数据而是等待中央服务器主动前来抓取Prometheus 提供多种类型的 Exporter 用于采集各种不同服务的运行状态。目前支持的有数据库、硬件、消息中间件、存储系统、HTTP 服务器、JMX 等Alertmanager是一个单独的服务可以支持 Prometheus 的查询语句提供十分灵活的报警方式。Prometheus HTTP API 的查询方式自定义所需要的输出Grafana 是一套开源的分析监视平台支持 GraphiteInfluxDBOpenTSDBPrometheusElasticsearchCloudWatch 等数据源其 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 用腾讯云或阿里云即可其相关系统较完善能轻松接入网宿在系统支持层面相对较弱一些而且还贵一些。并且当流量上来后CDN 不能只用一家需要用多家不同的CDN 在全国的节点覆盖不一样而且针对不同的客户云厂商内部有些区分客户集群并不是全节点覆盖但有些云厂商说自己是全网节点除了节点覆盖的问题多 CDN 也在一定程度上起到容灾的作用
