今天朋友圈被双黄连可抑制冠状病毒刷屏了，数据君温馨提示：大家千万不要在疫情扩散期去药店集中排队“抢药”，双黄连尚无有力证据证明疗效，但是它的广告语对“预防病毒”很有效： 您勤洗手，您多通风，人多不去凑热闹，多喝水，睡眠足，瓜果蔬菜牛奶好。 1 经 过 证 实 · · · 真 正 抗 病 毒 的 药

“计算机、互联网的世界里，有多少能真正被称为 ‘科学’的技术？数据库算得上一种。” 2019年，伴随着对这种“科学”的探索，国产数据库崛起势头强劲，国外数据库厂商技术垄断逐渐被打破。同时，在企业“全面上云”的背景之下，数据库行业云化趋势显著，整体市场的竞争态势从之前单一产品性能的PK逐渐过渡到以技术

农历新年即将到来， 对于新的一年，我们充满了期待。 从前车马很慢，书信很远， 一张小小的贺卡就能承载很多情谊。 想制作高大上的专属贺卡送给小伙伴？ 腾讯云教你1分钟coding程序猿专属贺卡， 保证私人定制，张张精美！ 参与coding就有机会免费获得 两千多元云代金券，先到先得！ 滑动下方图片查看

为帮助开发者更好的了解和运用数据库，腾讯云数据库团队特出品《深入浅出理解云数据库》系列文章，从数据库的基本概念到云数据库特性及应用，从数据库基础原理知识到腾讯云经典实战案例解读，带你走进云数据库的世界。关注“腾讯云数据库”微信公众号，开启2020年的DB修炼之旅。 第一回请点击：深入浅出理解云数据库

本文原作者：尹迪，经授权后发布。 1 原理 迭代再加权最小二乘(IRLS)用于解决特定的最优化问题，这个最优化问题的目标函数如下所示： $$arg min_{\beta} \sum_{i=1}^{n}|y_{i} - f_{i}(\beta)|^{p}$$ 这个目标函数可以通过迭代的方法求解。在每次

2019年匆匆而去，留下的是我们每一个人所有的努力，在新的一年里，它们将陪伴着我们继续新的征程，见证新的里程。年初是奋斗的季节，年末是收获的时刻，2019年的最后两个月，我们为您准备了这些“年货”： 弹性容器服务（ElasticKubernetesService，EKS）内测上线 TKE 节点原地滚

刚开始接触容器集群的人会发现，与在单节点上使用容器相比，容器集群一个很复杂的领域就是网络。Kubernetes 作为容器编排领域的事实标准，对容器集群的网络进行了合理抽象，并开放了容器网络标准 CNI，供各公司根据自身应用场景和底层基础设施选用开源方案或者自行实现一套网络插件。本文主要介绍腾讯云容器

| 导语 大规模的强化学习需要海量的异构计算资源，批量快速启停训练任务，高频更新模型参数，跨机跨进程共享模型数据等。传统的手工管理模式操作繁琐，面临诸多不确定性，带来的各种挑战无法支撑大规模强化学习的场景。本文介绍了腾讯内部某业务基于 TKE 构建大规模强化学习解决方案，以及与传统手工模式对比该方案

腾讯云 TKE Mesh 在 Kubecon-CloudNativecon China 2019 上对外发布, 以下是同场活动中「Application Level Networking」的现场demo部分. 1. 背景介绍 现场演示: 利用服务网格构建多分支环境 通过全链路跟踪系统进行服务性能分析

今天我们来分析istio中注入组件istio-sidecar-injector: 用户空间Pod要想加入服务网格, 首先需要注入sidecar container, istio 提供了2种方式实现注入: 自动注入方式: 利用 Kubernetes Dynamic Admission Webhooks

怎么给docker容器设置内核参数？ 怎么给k8s POD设置内核参数？ 为什么给容器设置某些内核参数之后，主机也会受影响？ 容器与sysctl 内核方面做了大量的工作，把一部分sysctl内核参数进行了namespace化(namespaced)。 也就是多个容器和主机可以各自独立设置某些内核参数

Istio 作为 Service Mesh 领域的集大成者, 提供了流控, 安全, 遥测等模型, 其功能复杂, 模块众多, 有较高的学习和使用门槛, 本文会对istio 1.1 的各组件进行分析, 希望能帮助读者了解istio各组件的职责、以及相互的协作关系. 1. istio 组件构成 以下是is

随着全球云计算产业高速发展，越来越多的企业选择业务上云，为了能够为广大用户提供更好、更全面的产品功能与使用体验，我们正在不断努力中。9月份，我们在容器服务的产品形态、功能支持以及用户体验上做了系列优化，并发布了如下特性： TKE 集群伸缩组相关 API 接入 API 3.0 TKE Kubernet

1. 测试背景： 目前基于k8s 服务的外网访问方式有以下几种： NodePort svc(通过k8s 的clusterip 访问) 自研 LB -> Pod （比如pod ip 作为 nginx 的 upstream, 或者社区的nginx-ingress） 其中第一种和第二种方案都要经过ipta

背景 测试环境没有真实的数据, 会导致很多测试工作难以展开, 尤其是一些测试任务需要使用生产环境来做时, 会极大影响现网的稳定性。 我们需要一个流量复制方案, 将现网流量复制到预发布/测试环境 期望 将线上请求拷贝一份到预发布/测试环境 不影响现网请求 可配置流量复制比例, 毕竟测试环境资源有限 零