Istio

导读： “数据就是一切！”我们都曾听过这种大胆的说法，但其实事实真是这样，而且数据还无处不在。如今，每个企业和组织发展都需要依赖大量的数据，数据也成为了企业最有价值的资产。为了让数据发挥最大的价值，通常我们都会采用数据库监控工具，本文将为大家介绍 6 款最好用的数据库监控工具。 作者 | Renaud Larue-Langlois 译者 | 甜梨、无明 / 来源：Infoq 在开始介绍这些工具之前，我们先简要介绍一下数据库监控的概念，然后谈论一下从硬件到存储过程中可监控的数据库元素，最后，我们将为大家推荐一些目前市面上可用、好用的数据库监控工具。（后台回复“监控”有开源监控工具推荐） 什么是数据库监控？ 正如数据就是组织的一切，监控是网络管理员的一切。现代网络纷繁复杂，由众多组件构成，我们不可能关注到所有的东西，尤其是在大型企业或组织中，管理员通常坐在与服务器不同的房间里，这时就需要监视工具了。 监控数据库与监控其他 IT 组件没有什么不同。数据库监控的主要目标是确保数据在需要时是可用的。这听起来很简单，但实际操作却相当复杂，部分原因在于组件的数量和种类。 虽然数据库是一个抽象概念，但它是由非常具体的东西组成的。从硬件到软件，数据库监控工具必须始终确保所有组件都是可用的，并且在正常范围内运行。 需要监控哪些东西？ 让我们更深入地了解一下数据库有哪些东西需要监控的

Helm 基本概念 Helm 可以理解为 Kubernetes 的包管理工具，可以方便地发现、共享和使用为Kubernetes构建的应用，它包含几个基本概念 Chart：一个 Helm 包，其中包含了运行一个应用所需要的镜像、依赖和资源定义等，还可能包含 Kubernetes 集群中的服务定义，类似 Homebrew 中的 formula，APT 的 dpkg 或者 Yum 的 rpm 文件， Release: 在 Kubernetes 集群上运行的 Chart 的一个实例。在同一个集群上，一个 Chart 可以安装很多次。每次安装都会创建一个新的 release。例如一个 MySQL Chart，如果想在服务器上运行两个数据库，就可以把这个 Chart 安装两次。每次安装都会生成自己的 Release，会有自己的 Release 名称。 Repository：用于发布和存储 Chart 的仓库。 Helm 组件 Helm 采用客户端/服务器架构，有如下组件组成： Helm CLI 是 Helm 客户端，可以在本地执行 Tiller 是服务器端组件，在 Kubernetes 群集上运行，并管理 Kubernetes 应用程序的生命周期 Repository 是 Chart 仓库，Helm客户端通过HTTP协议来访问仓库中Chart的索引文件和压缩包。 　　 安装步骤 1、

不知不觉，19年过去 了 一半。 半年发生了两件大事，使得写作时间减少： 工作满10年，接手了新的团队 ，对工作依然充满激情与动力 小宝宝1岁了 ，陪伴她的时间越来越多 无论如何，上半年做一个文章分类精选，大家 点击标题，直接阅读 。 底层硬核 《 写缓冲(change buffer)，这次彻底懂了！ 》 《 缓冲池(buffer pool)，这次彻底懂了！ 》 《 memcache内核实现细节 》 《 两个工具搞定MySQL死锁 》 《 微服务架构，脱不开的RPC细节 》 《 一次性搞透协议设计 》 《 一次性搞透搜索技术 》 画外音：下半年，争取多谢底层硬核。 ServiceMesh&Istio 《 ServiceMesh究竟解决什么问题？ 》 《 Istio究竟是干嘛的？ 》 《 Istio分层架构？80%的人有误解 》 《 Istio实现灰度发布，就是这么轻松 》 《 Istio流控、服务发现、负载均衡 》 画外音：超前的架构思路，似乎没啥人关注。 架构设计 《 1万属性，10万并发，100亿数据架构设计 》 《 一次性搞透高可用 》 《 一次性搞透高并发 》 《 微服务架构，多“微”才合适？ 》 《 架构优化，IP直通车 》 算法细节 《 拜托，面试别再问我最大值最小值了！ 》 《 拜托，面试别再问我表达式求值了！ 》 数据库 《 业界难题，跨库分页的几种方案 》 《

作者：Brian McClain & Bryan Friedman 译者：李寿景 审校：孙海洲、邱世达、徐鹏 Knative 是一个基于 Kubernetes 的，用于构建、部署和管理现代 serverless 应用的平台。Getting Started with Knative 是一本由 Pivotal 公司赞助 O’Reilly 出品的电子书，公众号后台回复“ knative ”获取英文版下载地址。本书中文版由 ServiceMesher 社区自发翻译系列文章，这是该系列的第5章。 在开始使用 Knative 构建和托管工作负载前，你需要安装它。你还应该运行一些命令来验证它是否正常运行并按预期工作。本章将介绍从 Mac 或 Linux shell 安装和验证 Knative 的必要步骤。 建立一个 Knative 集群 首先，你需要已经有一个 Kubernetes 集群。Knative 要求 Kubernetes 的版本在1.11以上。你必须在集群上启用 MutatingAdmissionWebhook admission controller。为了简单，你可以在本地机器上使用 Minikube 或者在云上运行集群。 为什么我们需要安装 Istio 迄今为止，我们还没讨论过 Istio，但是它作为安装的一部分出现了。Istio 是什么？Knative 为什么需要它？ Istio

作者 | 赵奕豪（宿何） Sentinel 开源项目负责人 来源| 阿里巴巴云原生公众号 前言 微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化，服务之间的依赖关系变得越来越复杂，业务系统也面临着巨大的高可用挑战。 在生产环境中大家可能遇到过各种不稳定的情况，比如： 大促时瞬间洪峰流量导致系统超出最大负载，load 飙高，系统崩溃导致用户无法下单。 “黑马”热点商品击穿缓存，DB 被打垮，挤占正常流量。 调用端被不稳定第三方服务拖垮，线程池被占满，调用堆积，导致整个调用链路卡死。 这些不稳定的场景可能会导致严重后果，但很多时候我们又容易忽视这些与流量/依赖相关的高可用防护。大家可能想问：如何预防这些不稳定因素带来的影响？如何针对流量进行高可用的防护？如何保障服务“稳如磐石”？这时候我们就要请出阿里双十一同款的高可用防护中间件 —— Sentinel。在今年刚刚过去的天猫 双11 大促中，Sentinel 完美地保障了阿里成千上万服务 双11 峰值流量的稳定性，同时 Sentinel Go 版本也在近期正式宣布 GA。下面我们来一起了解下 Sentinel Go 的核心场景以及社区在云原生方面的探索。 Sentinel 介绍 Sentinel 是阿里巴巴开源的，面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形

knative是较流行的serverless框架，目前参与的公司主要是 Google、Pivotal、IBM、Red Hat，目前迭代很快 knative 是建立在 kubernetes 和 istio 平台之上的，使用 kubernetes 提供的容器管理能力（deployment、replicaset、和 pods等），以及 istio 提供的网络管理功能（ingress、LB、dynamic route等） 对比kubeless，knative发展更快，大公司支持多 安装环境 kubernetes-1.19.* knative-0.19 istio-1.7.5 安装knative https://knative.dev/docs/install/any-kubernetes-cluster/ kubectl apply --filename https://github.com/knative/serving/releases/download/v0.19.0/serving-crds.yaml kubectl apply --filename https://github.com/knative/serving/releases/download/v0.19.0/serving-core.yaml 卸载不能直接删除命名空间，要通过 kubectl delete -