DevilKing's blog

人生到底什么，或许有些意义，或许也没有意义。。。

有些原则看起来很可笑，很迂腐，但值得内心平和地去坚持。。。

不要让焦虑去阻碍进步。。

本周工作：

• gp的token抓取集成
• 新的es部分重新灌入，后续保证删除，单机5亿条数据后，写入会非常地缓慢。。
• coinbot的初始部分完成

本周所得：

• golang重新恢复一些写法
• 关于okhttp3加入proxy

本周未完成：

• 关于rn的收尾工作

下周计划：

• rn的收尾工作
• golang的一些知识的总结
• 子渠道部分的一些算法

突然发生的事情，让人措手不及，怎么就沦为这样的地步，做最坏的打算，资金链崩坏，不再联系，双方见面也尴尬。。。还是希望度过这一难关吧，人还在，什么都有。。。

人是在了。。。不过感觉关系也就这样了，出了问题遮遮掩掩，并没有彻底地去解决问题。。。还背锅。。。自己自在地活着。。

还是这样，人畜无害地平庸地生存下去，这样挺好，低欲望，低消费，保持可笑的原则，慢慢走下去，与其说成探索人生，不如说在人生中去过一些地方，遇到一些人，碰到一些事，人生也是一场修行，正念，加油。。。

外包的事情，抓点紧，这快1个月过去了，感觉还只是1/4的样子。。。算是补贴下贷款吧。。

其他学习方面和工作上，也抓紧点。。

原文链接

单服务器组发布

手动发布，手动停掉-> 金丝雀发布，先发一组，做流量测试

滚动式发布

1. 滚动式发布一般先发 1 台，或者一个小比例，如 2% 服务器，主要做流量验证用，类似金丝雀 (Canary) 测试。
2. 滚动式发布需要比较复杂的发布工具和智能 LB，支持平滑的版本替换和流量拉入拉出。
3. 每次发布时，先将老版本 V1 流量从 LB 上摘除，然后清除老版本，发新版本 V2，再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。
4. 一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。
5. 回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。
6. 滚动式发布国外术语通常叫 Rolling Update Deployment。

双服务器组发布

为一次发布分配两组服务器，一组运行现有的 V1 老版本，一组运行待上线的 V2 新版本，再通过 LB 切换流量方式完成发布，这就是所谓的双服务器组发布方式。

蓝绿发布

金丝雀发布

滚动发布

其他发布以及测试

影子测试

1. 目标实现老的 legacy 服务迁移升级到新的 experimental 服务。
2. 测试开始前，需要在测试环境部署一份 legacy 服务和 experimental 服务，同时将生产数据库复制两份到测试环境。同时需要将生产请求日志收集起来，一般可以通过 kafka 队列收集，然后通过类似 goreplay附录 6.8这样的工具，消费 kafka 里头的请求日志，复制回放，将请求分发到 legacy 服务和 experimental 服务，收到响应后进行比对，如果所有响应比对成功，则可以认为 legacy 服务和 experimental 服务在功能逻辑上是等价的；如果有响应比对失败，则认为两者在功能逻辑上不等价，需要修复 experimental 并重新进行影子测试，直到全部比对成功。根据系统复杂度和关键性不同，比对测试时间短的可能需要几周，长的可达半年之久。
3. 影子测试因为旁路在独立测试环境中进行，可以对生产流量完全无影响。
4. 影子测试一般适用于遗留系统的等价重构迁移，例如.net 转 Java，或者 SQLServer 数据库升级为 MySQL 数据库，且外部依赖不能太多，否则需要开发很多 mock，测试部署成本会很高，且比对测试更加复杂和不稳定。

比较

北京是一个人人都想拥有政策去压制别人的世界，有些绝望。幸好，有那么一丝希望。

五圆，希望能一直相互陪伴。。认真地面对这个世界

本周工作：

• rn还差几个页面，基本摸到一些门道
• coinrobot部分，api部分，以及收发微信啥的。

本周所得：

• 微信通知的一个api部分
• rn部分

下周计划：

• 关于gp抓取的恢复以及监控
• 关于adInstall-kafka的重构部分
• rn几个页面整体完成，开始蓝牙部分的适配
• coinrobot部分，完成初步的设定

猫领完，后面是安静地陪伴成长了。。

租房的事情，算是搞定，后面，可能会进入所谓的同居阶段，慢慢改变一些，慢慢适应吧，也没有什么好失去的，不是已经有最坏的打算。。

关于家长会面。。。哎。。感觉很不确定。。感觉还是给不了想要的，可能。。哎。。

锻炼上，要继续坚持下去，健身房的还保持的不错。。。

学习上和工作，有些压迫感，关于外包的东西，要给点压力，做完。。。

青城山下白素贞，洞中千年修此身

一心向道无杂念，皈依三宝弃红尘

本周工作：

• react native 开始入门，做了几个页面

本周所得：

• rn的部分知识，这次相对于之前的入门有所好转，但rn的组件方式导致lib库太繁多。。

下周工作：

• 基本接入部分
• 排查相关的运维问题
• rn的基本成型，页面大致搞定，一些跳转方面

说好的四月下杭州计划，就这样匆匆忙忙的过程中完成。。

还是缺乏理性，尤其是一到性上，简直是精虫上脑，还吃了短效避孕药。。。希望没啥事。。哎。。渣男附体，苦笑。。

自己还是太挫了，不管是什么方面。。。还是包裹起来吧，保持一定的距离，做好自己，保持理性。。

保持计划性，保证计划的实施，稳定性，恒心和耐心，要保持一下去。。。

撸管什么的，不要想了。。戒掉。。不要放纵自己。。

努力工作，积极生活。。为自己鼓劲。。就算acer也有梦想。。

原文链接

Multiple container management platforms (Kubernetes, Mesosphere DC/OS, and Amazon ECS) have been adopted across the industry during the last two years, driving different benefits to a wide class of use cases. Additionally, a handful of web-scale companies have developed solutions on top of Apache Mesos to meet the unique needs of their organizations.

可以尝试看下apache mesos？

How is Titus different from other container platforms

• tight integration between Titus and both Amazon and Netflix infrastructure

  Titus has advanced ENI and security group management support spanning not only our networking fabric but also our scheduling logic. This allows us to handle ENIs and IPs as resources and ensure safe large scale deployments that consider EC2 VPC API call rate limits

  同亚马逊的结合

  We also worked with AWS on the design of IP target groups for Application Load Balancers, which brings support for full IP stack containers and AWS load balancing

• We choose this path to ensure a common developer and operational approach between VMs and containers. This is evident through our Spinnakerenablement, support in our service discovery (Eureka), changes in our telemetry system (Atlas), and performance insight technologies.

• scale

  • we run over a thousand different applications, with some being very compute heavy (media encoding), some being critical Netflix customer facing services, some memory and GPU heavy (algorithm training), some being network bound (stream processing), some that are happy with resource over commitment (big data jobs) and some that are not

    we do not believe there are off-the-shelf solutions that can take on each of these scale challenges

  • We always try to maintain a philosophy of “just enough” vs “just in case” with the goal of keeping things as simple and maintainable as possible.

  In the scheduling layer, we support advanced concepts such as capacity management, agent management, and dynamic scheduling profiles

• ​