Mobabel

Just One Pure ITer

Mobabel Blog

0

Nginx

[转]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

Container Test

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

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

0

Kubernetes

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

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

Ähnliches Foto 0

Database Partitioning&Scaling

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

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

0

MS Design Princinple

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

近年，Spring Cloud 俨然已经成为微服务开发的主流技术栈，在国内开发者社区非常火爆。我近年一直在一线互联网公司（携程，拍拍贷等）开展微服务架构实践，根据我个人的一线实践经验和我平时对 Spring Cloud 的调研，我认为 Spring Cloud 技术栈中的有些组件离生产级开发尚有一定距离。比方说 Spring Cloud Config 和 Spring Cloud Sleuth 都是 Pivotal 自研产品，尚未得到大规模企业级生产应用，很多企业级特性缺失（具体见我后文描述）。

0

SOA Architect to MS Architect

[转]重新理解微服务

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

Bildergebnis für 火车 0

MQ in distributed Architecture

[转]分布式系统之消息队列

1. 2. 一、MQ简介 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。 使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 3. 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。

0

Redis High Avaliable Scale Architect

[转]一个包含10节点的Redis集群实践案例

Redis 通常不会被用作主要的数据存储，但它在存储和访问可容忍丢失的临时数据（如度量指标、会话状态、缓存）方面却独有长处，并且速度非常快，不仅提供了最佳性能，还内置了一组非常有用的数据结构。它是现代技术栈中最常见的主要部件之一。 Stripe（一家做支付的硅谷创业公司）的速率限定器就是基于 Redis 构建的，这些限速器运行在一个 Redis 实例上。Redis 主服务器有一些用于失效备援的追随者，不过在任何时候，都只有一个节点在处理读写操作。 各种消息来源声称，一个 Redis 节点每秒可以处理百万次操作。尽管我们的操作没有那么多，但也不会很少。每个速率限定器都需要运行多个 Redis 命令，而每个 API 请求都要通过很多个速率限定器。所以，每个节点每秒钟需要处理数万次到数十万次的操作。 如果节点出现饱和，就会不断出现故障。我们的服务可以容忍 Redis 的不可用，因此大多数情况下是没有问题的，但在某些情况下，问题的严重程度会升级。我们最后通过迁移到包含 10 节点的 Redis 集群来解决这个问题。对性能的影响可以忽略不计，重要的是现在我们可以实现水平可伸缩。