Mobabel Blog

0

[转]聊聊Chaos Engineering的历史、原则和最佳实践

  随着微服务和分布式云架构的崛起,Web 变得日趋复杂,“随机性”的故障因此变得越来越难以预测,而我们对这些系统的依赖却与日俱增。 这些故障给公司造成巨大损失,也给用户带来很大的麻烦,影响他们进行在线购物、交易或打断他们的工作。即使是一些简单的故障也会触及公司的底线,因此,宕机时间就成为很多工程团队的 KPI。2017 年,有 98% 的企业表示,一小时的宕机时间将给他们带来超过 10 万美元的损失。一次服务中断有可能让一个公司损失数百万美元。最近,英国航空的 CEO 透露,2017 年 5 月发生的一次技术故障造成数千名乘客滞留机场,给公司造成 8000 万英镑的损失。 企业需要想办法解决这些问题,因为等到下一次事故发生就为时已晚。为此,混沌工程(Chaos Engineering)应运而生。 混沌工程(Chaos Engineering)旨在将故障扼杀在襁褓之中,也就是在故障造成中断之前将它们识别出来。通过主动制造故障,测试系统在各种压力下的行为,识别并修复故障问题,避免造成严重后果。 混沌工程将预想的事情与实际发生的事情进行对比,通过“有意识地搞破坏”来提升系统的弹性。 混沌工程简史 混沌工程最先出现在互联网巨头公司中,这些公司拥有大规模的分布式系统,因为这些系统太过复杂,他们需要一些新的手段来测试它们。 2010 年 Netflix Eng Tools 团队开发出了 Chaos Monkey。当时,Netflix 从物理基础设施迁移到 AWS...

[转]58到家MySQL军规升级版 0

[转]58到家MySQL军规升级版

一、基础规范 表存储引擎必须使用InnoDB   表字符集默认使用utf8,必要时候使用utf8mb4 解读: (1)通用,无乱码风险,汉字3字节,英文1字节 (2)utf8mb4是utf8的超集,有存储4字节例如表情符号时,使用它

0

[转]Nginx宣布正式支持gRPC,附示例代码

  NGINX 官方博客正式宣布 NGINX 支持原生的 gPRC,现在就可以从代码仓库拉取快照版本。该特性将会被包含在 NGINX OSS 1.13.10、NGINX Plus R15 以及 NGINX 1.13.9 当中。 NGINX 已经能够代理 gRPC TCP 连接,用户可以用它: 发布 gRPC 服务,并应用 NGINX 提供的 HTTP/2 TLS 加密机制、速率限定、基于 IP 的访问控制以及日志等功能。 在单个端点上发布多个 gRPC 服务,使用 NGINX...

0

[转]MySQL是如何做容器测试的?

随着容器基础设施的出现,容器基础设施的测试变得与机器镜像的测试一样重要。 传统的基础设施管理是一项手动任务,由系统管理员管理静态服务器。现代云平台的自动化能力改变了这种工作方式:基础设施通常被描述为“代码”,基础设施管理系统会对基础设施自动做出变更。因此,基础设施的变得更加动态,周转时间也要短得多。 基础设施测试框架通常被用于验证机器镜像的状态(Amazon Machine Images、Google Compute Images 或 Oracle OCI Images)。随着容器基础设施的出现,容器基础设施的测试变得与机器镜像的测试一样重要。 在 MySQL,我们有很多基础设施,我们越来越多地使用容器来代替真实(虚拟)机器。此外,越来越多的核心基础设施运行在 Oracle 的云基础设施(OCI)上。这要求我们实现多个级别的自动化,并且可以利用基础设施测试来验证我们的服务器(或虚拟机、容器)的状态。基础设施测试还用于验证我们发布的一些工件的状态。 在这篇博文中,我们将重点介绍如何使用自动化基础设施测试来验证 MySQL Server Docker 镜像。我们将比较三个可用于进行容器测试的框架,并给出示例代码。

0

[转]Kubernetes上的十大应用程序

在崭新的 Kubernetes 集群上,经常会安装的 helm chart 都有哪些呢? 在崭新的 Kubernetes 集群上,经常会安装的 helm chart 都有哪些呢?下面这个清单代表了我们的观点。 序号 名称 理由 1 nginx-ingress 世界上最常见的前端代理,非常易于搭建,功能具有通用性。根据场景的不同,可能会有更好的 Ingress,但是它的份额占到了 99%。 2 coredns Kubernetes 上最好的 DNS 服务器。默认的 KubeDNS 比较糟糕,所以毫无疑问你需要将它切换掉。借助 coredns 你还可以启用一些很酷的插件,使其能够与其他的应用程序协作,比如 Prometheus。 3 Prometheus 每个人都应该使用...

Ähnliches Foto 0

[转]分表分库时机选择及策略

一. 分表 应用场景: 对于大型的互联网应用来说,数据库单表的记录行数可能达到千万级甚至是亿级,并且数据库面临着极高的并发访问。采用Master-Slave复制模式的MySQL架构,只能够对数据库的读进行扩展,而对数据库的写入操作还是集中在Master上,并且单个Master挂载的Slave也不可能无限制多,Slave的数量受到Master能力和负载的限制。 因此,需要对数据库的吞吐能力进行进一步的扩展,以满足高并发访问与海量数据存储的需要!

0

[转]一个可供中小团队参考的微服务架构技术栈

近年,Spring Cloud 俨然已经成为微服务开发的主流技术栈,在国内开发者社区非常火爆。我近年一直在一线互联网公司(携程,拍拍贷等)开展微服务架构实践,根据我个人的一线实践经验和我平时对 Spring Cloud 的调研,我认为 Spring Cloud 技术栈中的有些组件离生产级开发尚有一定距离。比方说 Spring Cloud Config 和 Spring Cloud Sleuth 都是 Pivotal 自研产品,尚未得到大规模企业级生产应用,很多企业级特性缺失(具体见我后文描述)。 另外 Spring Cloud 体系还缺失一些关键的微服务基础组件,比如 Metrics 监控,健康检查和告警等。所以我在参考 Spring Cloud 微服务技术栈的基础上,结合自身的实战落地经验,也结合国内外一线互联网公司(例如 Netflix,点评,携程,Zalando 等)的开源实践,综合提出更贴近国内技术文化特色的轻量级的微服务参考技术栈。希望这个参考技术栈对一线的架构师(或者是初创公司)有一个好的指导,能够少走弯路,快速落地微服务架构。

0

[转]重新理解微服务

微服务是个说的挺长时间的概念,也是比较成熟的技术体系。像 Spring Cloud,甚至提供了微服务所需要的全套框架,包括注册中心 (Eureka)、配置中心 (Config)、断路器 (Hytrix)、API 网关 (Zuul) 等组件。微服务体系庞杂,每个组件都能独自成章。本文作者仅从个人的经验和实践出发,谈了谈自己对微服务及其部分内涵的思考和理解。 作者张轲目前任职于杭州大树网络技术有限公司,担任首席架构师,负责系统整体业务架构以及基础架构,熟悉微服务、分布式设计、中间件领域,对运维、测试、敏捷开发等相关领域也有所涉猎。