-
编辑 删除
深入解读Service Mesh的数据面Envoy
在前面的一篇文章中，详细解读了ServiceMesh中的技术细节，深入解读ServiceMesh背后的技术细节。但是对于数据面的关键组件Envoy没有详细解读，这篇文章补上。一、Envoy的工作模式Envoy的工作模式如图所示，横向是管理平面。Envoy会暴露admin的API，可以通过API查看E
-
编辑 删除
用双十一的故事串起碎片的网络协议（下）
欢迎你留言和我讨论。趣谈网络协议，我们下期见！上一节，我们封装了一个长长的网络包，“大炮”准备完毕，开始发送。发送的时候可以说是重重关隘，从手机到移动网络、互联网，还要经过多个运营商才能到达数据中心，到了数据中心就进入第二个复杂的过程，从网关到VXLAN隧道，到负载均衡，到Controller层、组
-
编辑 删除
用双十一的故事串起碎片的网络协议（中）
上一节我们讲到，手机App经过了一个复杂的过程，终于拿到了电商网站的SLB的IP地址，是不是该下单了？别忙，俗话说的好，买东西要货比三家。大部分客户在购物之前要看很多商品图片，比来比去，最后好不容易才下决心，点了下单按钮。下单按钮一按，就要开始建立连接。建立连接这个过程也挺复杂的，最终还要经过层层封
-
编辑 删除
用双十一的故事串起碎片的网络协议（上）
在经济学领域，有个伦纳德·里德（LeonardE.Read）创作的《铅笔的故事》。这个故事通过一个铅笔的诞生过程，来讲述复杂的经济学理论。这里，我也用一个下单的过程，看看互联网世界的运行过程中，都使用了哪些网络协议。我把这个过程分为十个阶段，从云平台中搭建一个电商开始，到BGP路由广播，再到DNS域
-
编辑 删除
微服务化之服务拆分与服务发现
本文章为《互联网高并发微服务化架构实践》系列课程的第六篇前五篇为：微服务化的基石——持续集成微服务的接入层设计与动静资源隔离微服务化的数据库设计与读写分离微服务化之无状态化与容器化微服务化之缓存的设计一、服务拆分的前提说到微服务，服务拆分是绕不过去的话题，但是微服务不是说拆就能拆的，有很多的前提条件
-
编辑 删除
深入解读Service Mesh背后的技术细节
在Kubernetes称为容器编排的标准之后，ServiceMesh开始火了起来，但是很多文章讲概念的多，讲技术细节的少，所以专门写一篇文章，来解析ServiceMesh背后的技术细节。一、ServiceMesh是Kubernetes支撑微服务能力拼图的最后一块在上一篇文章为什么kubernetes
-
编辑 删除
为什么 kubernetes 天然适合微服务
最近总在思考，为什么在支撑容器平台和微服务的竞争中，Kubernetes会取得最终的胜出，事实上从很多角度出发三大容器平台从功能方面来看，最后简直是一摸一样。参考Docker,Kubernetes,DCOS不谈信仰谈技术容器平台选型的十大模式：Docker、DC/OS、K8S谁与当先？经过一段时间的
-
编辑 删除
为什么 kubernetes 天然适合微服务
最近总在思考，为什么在支撑容器平台和微服务的竞争中，Kubernetes会取得最终的胜出，事实上从很多角度出发三大容器平台从功能方面来看，最后简直是一摸一样。参考Docker,Kubernetes,DCOS不谈信仰谈技术容器平台选型的十大模式：Docker、DC/OS、K8S谁与当先？经过一段时间的
-
编辑 删除
微服务化之缓存的设计
本文章为《互联网高并发微服务化架构实践》系列课程的第五篇前四篇为：微服务化的基石——持续集成微服务的接入层设计与动静资源隔离微服务化的数据库设计与读写分离微服务化之无状态化与容器化在高并发场景下，需要通过缓存来减少数据库的压力，使得大量的访问进来能够命中缓存，只有少量的需要到数据库层。由于缓存基于内
-
编辑 删除
有关容器的六大误区和八大正确场景
做容器的研究和容器化几年了，从最初对于容器的初步认识，到积攒了大量的容器迁移经验，并和客户解释了容器技术之后，发现原来对于容器的理解有大量的误解，而且容器并非虚拟机的替代，而是有十分具体的应用场景的。第一部分：容器的理解误区误区一：容器启动速度快，秒级启动这是很多人布道容器的时候经常说的一句话，往往
-
编辑 删除
终于有人把云计算、大数据和人工智能讲明白了！
这篇文章发在博客上https://www.cnblogs.com/popsuper1982/p/8505203.html，后来转到DBAplus社群，没想到竟然火了一把，再转回来给我的公众号的朋友们。DBAplus的排版和起标题的水平比我专业多了，可以点击原文链接查看DBAplus里面的文章。今天跟
-
编辑 删除
微服务化之无状态化与容器化
本文章为《互联网高并发微服务化架构实践》系列课程的第四篇前三篇为：微服务化的基石——持续集成微服务的接入层设计与动静资源隔离微服务化的数据库设计与读写分离一、为什么要做无状态化和容器化很多应用拆分成微服务，是为了承载高并发，往往一个进程扛不住这么大的量，因而需要拆分成多组进程，每组进程承载特定的工作
-
编辑 删除
微服务化的数据库设计与读写分离
数据库永远是应用最关键的一环，同时越到高并发阶段，数据库往往成为瓶颈，如果数据库表和索引不在一开始就进行良好的设计，则后期数据库横向扩展，分库分表都会遇到困难。对于互联网公司来讲，一般都会使用Mysql数据库。一、数据库的总体架构我们首先来看Mysql数据的总体架构如下：这是一张非常经典的Mysql
-
编辑 删除
基于容器云的深度学习体验
当前深度学习如火如荼，而深度学习平台多依赖于GPU。网易容器云也计划推出基于GPU的容器，目前在灰测阶段，先来体验一把。(1)在容器服务中，创建有状态负载在最新的可用区B，选择高性能容器，选择异构计算，就是带GPU的容器了既然是容器，要选择一个容器镜像，可以用官网的public/gpu-runtim
-
编辑 删除
微服务的接入层设计与动静资源隔离
这个系列是微服务高并发设计，所以我们先从最外层的接入层入手，看都有什么样的策略保证高并发。接入层的架构画一个简图来讲包括下面的部分接下来我们依次解析各个部分以及可以做的优化。一、数据中心之外：DNS，HttpDNS，GSLB当我们要访问一个网站的服务的时候，首先访问的肯定是一个域名，然后由DNS，将
-
编辑 删除
微服务化的基石——持续集成
一、持续集成对于微服务的意义：拆之前要先解决合的问题在很多微服务化的文章中，很少会把持续集成放在第一篇，因为大多数的文章都会将如何拆的问题，例如拆的粒度，拆的时机，拆的方式。为什么需要拆呢？因为这是人类处理问题的本质方式：将一个大的复杂问题，变成很多个小问题解决。所以当一个系统复杂到一定程度，当维护
-
编辑 删除
IT云厂商和互联网云厂商在ToB领域的几个回合？
之所以写这篇文章，是因为前一段时间很火的一篇文章《互联网公司的ToB梦，是理想还是春梦》，这篇文章的很多观点真真实实的戳到了我的心缝儿里，作为一个既在IT厂商工作过，也在互联网厂商工作过的解决方案架构师，对于这两种厂商的玩法都各有了解，但是本人冷静思索之后，发现两种玩法各有所长，并相互交锋中相互学习
-
编辑 删除
最牛云厂商的最牛解决方案盘点(1)
当前云计算如火如荼。云计算厂商也如雨后春笋一般冒了出来。林林总总的云计算厂商。作为甲方应该如何选型呢？这些重要的云计算厂商都有哪些牛的解决方案呢？这篇文章中我来给大家一一盘点。我们对云计算厂商按以下几个维度进行划分。首先是商业化产品还是开源产品。商业化的产品的好处是稳定，成熟，性能好，毕竟一个非常大
-
编辑 删除
从互联网+角度看云计算的现状与未来
现状互联网这个词已经无人不说，无人不讲，大概归功于罗振宇的罗辑思维对于互联网概念的极力宣扬，似乎不加上互联网三个字，你的企业宣传都张不开嘴。于是互联网+这个名词就随处可见了。支撑互联网化的一个重要的力量就是云计算，但现在的云已经外延被扩大的不知道到哪里去了，什么财务云，发票云等等等等，让我们这些做计
-
编辑 删除
这个一个月没有更新的公众号的作者，他在支撑双十一
上一篇更新的公众号文章是在10月11，距离双十一一个月的时间，各大电商平台的技术人员就都已经开始摩拳擦掌，厉兵秣马，迎接这一年一度的电商盛会，从朋友圈看出，大家都卖的很成功，我们也实现了28分钟就卖出了去年整个双十一的量，办公室里面顿时敲锣打鼓，红旗招展。能够平稳支撑过双十一着实不容易，如果前期没有
