唯品会基本每个月都有优惠。例如618唯品会特卖节、满199减100、新用户包邮等。

好像9月9日有优惠活动，然后10月1号也有优惠活动，个人认为每年的12月8号举办的优惠活动优惠力度最大。

唯品会信息科技有限公司（VIPS）成立于2008年8月，总部设在广州，旗下网站于同年12月8日上线。唯品会主营业务为互联网在线销售品牌折扣商品，涵盖名品服饰鞋包、美妆、母婴、居家等各大品类。2012年3月23日，唯品会在美国纽约证券交易所（NYSE）上市。目前唯品会已成为中国第三大电商。唯品会2017年总营收为人民币729亿元，增长28.8%。

唯品会在中国开创了“名牌折扣+限时抢购+正品保障”的创新电商模式，并持续深化为“精选品牌+深度折扣+限时抢购”的正品特卖模式。这一模式被形象地誉为“线上奥特莱斯”。唯品会每天早上10点和晚上8点准时上线200多个正品品牌特卖，以最低至1折的折扣实行3天限时抢购，为消费者带来高性价比的“网上逛街”的购物体验。

在美国权威财经杂志《财富》发布的2017中国500强榜单中，唯品会位列第115名，并位列B2C电商第三。而在《财富》杂志同期发布的 “2017年中国500强净资产收益率最高40家公司”榜单中，唯品会凭借35.53%的资产收益率位列第三名，稳居互联网行业第一。

2017年6月，唯品会宣布品牌定位升级，从“一家专门做特卖的网站”，升级为“全球精选，正品特卖”。

截至2017年12月31日，唯品会已连续21个季度保持盈利。

唯品会在美国零售行业杂志《Stores》联合德勤发布的《2017全球250强零售商排行榜》中，蝉联“全球增速最快的顶尖零售商”。在BrandZ?《2017年最具价值中国品牌100强》中，唯品会排名第40位，并获“最佳新晋中国品牌”称号。

【编者的话】Noah云平台从2017年初调研开发到现在，已经一年多时间了，虽然背靠开源技术框架，但在此基础上结合唯品会的技术体系，做了很多重要的功能开发和二次开发，本次分享想给大家介绍下我们的实现细节，从面到点，慢慢的介绍唯品会云平台的发展和壮大的过程，也会给大家介绍下我们的经验和踩过的一些坑。

唯品会Noah云平台的构建历程

Noah云平台从2017年初开始调研，3月份确定选型和架构，7月份已经开始接入业务，到现在已经研发了1年半时间，现在部署了5个IDC，共9个Kubernetes集群（有些IDC部署了两套Kubernetes集群），其中两套Kubernetes集群供AI使用。

这里讲些我们建设云平台的目标，主要从资源利用率提升，开发测试运维一致性和对DevOps的进化三个目标，其实就是提高人效和机器效率。

Noah云平台整体架构

Noah云平台整体架构按架构层次，分为主机层，容器层，云平台层（后面说的Noah Server），其中容器调度使用了业界开源的Kubernetes

为了实现集群的高可用，Noah云平台提供多个IDC部署，业务可以同时部署到不同的IDC的Kubernetes集群，但核心业务对延时要求非常敏感，业务容器依赖的第三方服务还没有做到MHA，如数据库MySQL，Redis。这样容器多机房部署后，容器调用就变成跨机房调用。

为了提高集群的高可用，同时也防止跨机房调用，Noah云平台把一个IDC的大集群，拆成两个小集群，业务容器只需部署到同机房的两个集群，这样不单可以解决跨机房调用问题，也可以防止Kubernetes集群过大导致的调度性能问题。

聪明的你也会问，如果整个IDC都不可用怎么办？Noah云平台其实也提供了解决办法。

• 多IDC网络形成环路，避免光纤被挖断的尴尬
• 提供一键容灾迁移功能，快速迁移业务域的容器到其他机房（有几分钟的服务不可用）

容器网络也是Noah云平台最重要的一环了，容器网络的互通性，性能是保证容器化推进顺利催化剂。因此我们的网络方案也做了很多调研和优化。容器网络方案使用Kubernetes CNI模型。

对比不同的容器网络类型：隧道方案 vs VLAN方案 vs 路由方案，我们最后选型的是Contiv Netplugin。

这里说下我们网络方案优化的地方，为了让新增容器业务不增加现有核心ARP表压力，网关下移至TOR交换机，核心/汇聚交换机无需承载ARP，仅需运行路由协议或静态路由，可增加核心可靠性。

• 统一分配，管理子网与IP地址池，管理Docker网络，配置数据同步更新etcd

• 监听etcd，实时更新网络信息缓存

• 桥接容器与物理网口，承载来自容器业务流量转发
• ACL访问控制和QoS限流

• 存储contiv网络数据模型，包括网络名，endpoint,ip地址池等信息，传递网络状态更新事件

唯品会早就已经有自己的日志监控（Dragonfly），业务监控（Mercury）和物理机监控（Falcon）系统。但它们也需要监控容器，因此也做不少工作。

容器指标，我们开发了smart agent，它除了收集业务的trace log日志外，还收集业务自定义的metric指标，容器性能指标等。同时它也会触发告警，我们在告警时增加了命令执行钩子，这样可以在发生告警时做一些action，比如收集当时的dstat，收集容器进程的vjdump和火焰图等。

由于本文关注的是Noah云平台，因此这里就不详细展开日志和监控系统的架构了。

Kubernetes提供了Liveness Prob，如果Health Check不过，容器会自动重启，但这样就没有现场了，业务就比较困难定位问题，所以Noah云平台在容器Health Check不过导致的容器重启，会自动执行唯品会开源的vjtools工具的vjdump命令，抓取当前的snapshot。

agent会收集业务域目录下指定文件，如/apps/logs/log_receiver/{domain-name}/xxxx.log，但容器化后，同一个业务容器可能跑到同一台宿主机上，如果按照原来的log路径mount到宿主机的话，会导致两个容器同时写同一个日志问题，导致log错乱等问题。

如果业务需要线上容器来定位问题，可以先把某个容器的流量摘掉就可以了，但若想保证容器的instance数量，怎么做呢？Noah云平台使用了K8S ReplicaSet Selctor的特性，如RS有selector：[a=b, c=d]，则含有且不限于label：[a=b,

鉴于此特性，如果想将某个容器隔离出当前的RS，只需要修改此容器的label即可，为了能够方便查询被隔离的容器，Noah云平台把label修改为[name-bk=deployName，pod-status=isolate]的方式。

官方文档已经有说什么叫Voluntary和Involuntary场景，我这里就不在多说了：

我这里说下Noah云平台怎样巧用PDB。在我们做集群机器的内核升级过程中（需重启机器），为了保证升级过程不中断业务，运维必须按机柜来重启机器，因为如果多机柜同时操作的话，如果某个业务域的容器刚好都在这批重启的机柜上，那这服务就中断了。

这时，我们使用PDB。在升级前，为Kubernetes集群中每个Deployment创建PDB［一个脚本搞定］，然后运维升级内核重启机器就不需要按机柜逐个做了，就把大集群的机器分多批来做，在执行kubectl drain命令的时候，PDB会产生效果，保证业务容器的最低Running Instance个数，如果少于最低Running

我们使用这种方式，以前几百台机器都要升级一个下午，现在基本1小时能够完成上千台机器的内核升级重启。当然这是我们使用PDB的例子，但其实也有很多地方可以使用的，比如ZooKeeper，etcd要保证最少容器数等。

生产服务器默认都调整为Performance模式的，但在CPU是E5-2630 v4这个型号的华为机器不生效。这里分享下我们的经验。

• 系统交付时，检查/proc/cpuinfo的cpu主频是否跟硬件主频一致

在系统高IO的情况下，如果不设置dirtybackgroundbytes，默认使用dirtybackgroundratio的设置，默认是10，在现在动不动几十G内存的机器，值非常大，当把这么大量的page cache数据刷到磁盘上的时候会超过普通磁盘的iops。因此我们设置这个参数，满100M就刷盘。

操作系统OS的swapniess默认是60，这是Linux在很久的时候设置的默认值，可能当时内存容量没现在这么大吧，但现在这个默认值已经不合适了。如果不修改，那内存剩下很多就开始用swap了，用了swap，各种超时就出来了。因为容器的内存是根据JVM Heap计算出来的，通常都比JVM Heap要大，因此我们把swapiness修改为0。

业务容器化后，运行时线程数暴涨，后来分析后，根本原因是很多框架或第三方库，都是通过Runtime.getRuntime().availableProcessors()获取CPU核数来计算线程数，很悲剧的是，JDK 1.9以下版本都只能获取物理机的核数，这样导致线程数超多，由于容器的CPU资源受限，因此这么多线程数，导致Context Switch增大，从而消耗CPU和影响性能。

根本原因是1.9.8默认打开了OS的Kernel Memory，而我们用的内核版本的Kernel Memory是不稳定的。回想起问题定位过程，真的非常艰巨，连续几天披星戴月啊……当然我们也总结了踩坑过程：《 》。

升级内核到4.x版本风险大，最后折衷，通过修改了Kubernetes一行代码，暂时关闭Kernel Memory功能，暂时解决这个问题。

我们在Kubernetes GitHub上提的 ，然后发现很多人都遇到相同的问题。

这里说说我们正在做和准备做的一些事情，希望能引起一些大家的讨论。

Operator是由CoreOS开发的，用来扩展Kubernetes API，特定的应用程序控制器，它用来创建、配置和管理复杂的有状态应用。有些集群需要一些特殊操作才能构建起来，如etcd，Redis Cluster，Kubernetes提供的StatefulSet不能满足这些需求。因此Kubernetes提供了CRD（自定义控制器）的方式，让我们可以扩展，其中Operator就是一系列应用程序特定的自定义控制器。

• Operator使用Informer组件，监听资源状态。当资源发生变化时，根据事件类型调用对应的callback函数。

篮色部分为Kubernetes已提供的开发组件，红色部分即我们需要实现的模块：

MySQL Operator的存储是使用了分布式Ceph存储，性能方面不能满足生产需求，DBA希望MySQL容器可以使用本地的SSD，因此我们需要基于Local Stroage的容器调度。

• 未绑定PVC：该PVC是否需要延时绑定，如需要，遍历未绑定PV，其NodeAffinity是否匹配候选Node，如满足，记录PVC和PV的映射关系到缓存bindingInfo中，留待节点最终选出来之后进行最终的绑定

有些业务希望容器能够在本地做patch重启，比如第一次发布根据调度规则把容器部署到不同的节点上，后面的新版本发布，他们希望新容器能够在以前的节点上重启容器。该需求的目的是容器与物理机相对固定，业务就可以做一些事情，比如一些降级文件可以只下载一次，不需要每次发布都下载一次降级文件（降级文件比较大），还有一些目的是加快容器启动速度，锁定容器资源，重用数据卷等。

当然容器本地rebuild会丧失容器调度的能力，因此只会对某些域开放。

容器本地rebuild实现后，容器的IP相对就固定了，因为patch容器的时候，Kubernetes pause容器没有被重启，只重启业务容器，因此容器的IP是不变的。我们在此基础上，结合我们容器网络拓扑的特殊性（因为网关下沉到机柜上，所以容器IP与机架必须对应），开发了容器固定IP。

以上是唯品会Noah云平台在总体架构，它构建与开源的生态框架，但又做了一些二次开发来满足唯品会云平台的需求，本文通过云平台标配功能的实现细节，服务注册发现实现原理，资源优化方法，容器隔离方案，容器高可用性方案，容器网络方案，一些实现的小技巧和解决过的问题等维度做了比较详细的介绍，希望这些方案和实现细节，能帮助大家在实现自己的云平台有所帮助。

Q：灰度发布时，两个应用前要加负载均衡吗？

A：我在服务注册发现章节提到唯品会有自研的服务化框架，是通过服务化框架的Proxy做LB的，LB是服务治理的一个重要功能。对于HTTP服务，最后还是注册到HAProxy的，因此还是通过它做LB的。

Q： 有状态的服务比如IP固定，不知道你们有没有这种服务，是怎么解决的？

A：我们是有写有状态的服务，如Redis和MySQL，是通过CentOS Operator框架，自己编写Operator解决的。固定IP我们正在开发中，因为要结合唯品会的网络拓扑，实现起来稍微复杂点。还有，我们在做的rebuild方案，IP也是相对固定的，如果没有触发Kubernetes的scheduler调度的话，比如node evict。

Q：请问，外部请求如何路由到Kubernetes集群内，是使用的Ingress吗？

A：外部流量的接入，唯品会有VGW的Gateway，通过APP上的智能路由找到最优机房的VGW，然后一层一层到容器。

Q：超配的情况下，如果各个pod load都增大，驱逐策略是怎样的？

A：这里我没有讲细，你的问题很仔细啊，赞，我们开发了热点迁移容器的API，监控系统如果收到告警（比如CPU过高，IO过高），会调用我们API ，我们API获取实时的监控数据，根据某个算法，迁移走部分热点容器。

Q：自动缩容的时候是如何选择Pod，如何保证数据不丢失呢？

A：自动缩容之针对无状态应用的，而且我们要求所有上云平台的应用，都支持Graceful Shutdown，由业务保证。

Q：Tomcat类应用容器Xmx内存分配多少比例合适，就是Xmx使用百分多少容器内存合适？

A：JVM内存的计算包括了Heap＋Permgen＋线程数的stack（1M／per线程）＋堆外内存，所以我们监控容器的RSS数据，这是容器真实的内存占用。

Q：集群空闲率多少合适？我们的集群超过60%上面的容器就不稳定了。

A：我们为了提高资源利用率，做了很多事情，上面有说到，你说的60%就不稳定，需要具体分析下，因为我们也踩过一些Kubernetes和Docker的坑，同时也需要优化好系统参数，有时候问题也跟内核版本有关。

以上内容根据2018年9月18日晚微信群分享内容整理。分享人 王志雄，唯品会云平台架构师，参与工作15+，其中10多年在亿讯（中国电信），爱立信参与电信领域产品开发研究工作，4年前加入唯品会基础架构部，主要负责服务化平台（唯品会OSP）的研发和推广落地工作，OSP现已经是唯品会主流的服务化框架。17年开始云平台产品相关工作，现是唯品会云平台架构师，主要负责唯品会Noah云平台的产品研发和推广落地工作，Noah云平台已经接入了大部分核心域和其他业务域，并顺利承载了公司的多次大促 。DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesd，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。