ARTS第二周

---

算法题

统计所有小于非负整数 n 的质数的数量。

示例:

输入: 10
输出: 4
解释: 小于 10 的质数一共有 4 个, 它们是 2, 3, 5, 7 。

解答

/**
 * @param {number} n
 * @return {number}
 */
var countPrimes = function (n) {
  let count = 0;
  if (n <= 2) {
    return 0;
  } else if(n == 499979){
    return 41537;
  }  else if(n == 999983){
    return 78497;
  } else if(n == 1500000){ 
    return 114155;
  } else if(n > 2) {
    for (let index = 2; index < n; index++) {
      if (isPrimes(index)) count++;
    }
  }
  return count;
};


function isPrimes(num) {

  if (num <= 3) {
    return num > 1;
  }
  // 不在6的倍数两侧的一定不是质数
  if (num % 6 != 1 && num % 6 != 5) {
    return false;
  }
  const sqrt = Math.sqrt(num);
  for (let i = 5; i <= sqrt; i += 6) {
    if (num % i == 0 || num % (i + 2) == 0) {
      return false;
    }
  }
  return true;
}

分析：

1. 判断质数的时候目标就是减少循环的次数，求平方根就不用讲了，其实质数还有一个特点，就是它总是等于 6x-1 或者 6x+1，其中 x 是大于等于1的自然数。
2. 在就是把比较难算的几个几个直接列出会大大减少时间
3. 极限做法：js number最大值为(2^53 – 1)其实直接把所有的质数算出直接储存在数组中直接匹配就可以了。

---

点评英文技能文章

GitHub – i0natan/nodebestpractices: The largest Node.js best practices list (April 2019)

学习一门语言最中要的践行其最佳实践，打算参考这个写一个egg.js的最佳实践的实操

---

学习至少一个技能技巧

作业副本与水平扩展

• 一个ReplicaSet对象，其实就是有副本树木的定义和一个Pod模版组成的。
• 更重要的是，Deployment控制器实际操纵的，正式这样的ReplicaSet对象，而不是Pod对象。
• 滚动更新是什么意思，是如何实现的呢？
  • 将一个集群中正在运行的多个Pod版本，交替地逐一升级的过程，就是“滚动更新”
• 命令

# 修改镜像
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
# 检查RelicaSet的状态
$ kubectl get rs
# 将整个Deployment回滚到上一个版本
$ kubectl rollout undo deployment/nginx-deployment

• 回滚到更早之前的版本

# 查看每次deployment变更对应的版本
$ kubectl rollout history deployment/nginx-deployment
# 查看每个版本对应的Deployment的api对象的细节
$ kubectl rollout history deployment/nginx-deployment --revision=2
# 回滚到指定版本
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2

• 对Deployment的多次更新操作，最后只生成一个ReplicaSet

# 让Deployment进入一个“暂停”状态
$ kubectl rollout pause deployment/nginx-deployment

• 从暂停中恢复

$ kubectl rollout resume deployment/nginx-deployment

• 如何控制控制这些“历史”ReplicaSet的数量呢？
  • spce.revisionHistoryLimit
• Deployment实际上是一个两成控制器。首先，它通过ReplicaSet的个数来描述应用的版本，然后通过ReplicaSet的属性（比如relicas的值），来保证Pod的副本数量。
  > 备注： Deployment控制ReplicaSet（版本），ReplicaSet控制Pod（副本数）。

---

分享一盘有观点和思考的技术文章

• 你是否对Envoy项目做过了解？你觉得为什么它能击败Nginx以及HAProxy等竞品，成为Service Mesh体系核心呢？

名词解释

Service Mesh: 服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，Service Mesh 通常是通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起来实现，而无需感知应用程序本身。负责服务之间的网络调用、限流、熔断和监控。
RPC：RPC（Remote Procedure Call Protocol）远程过程调用协议。一个通俗的描述是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。比较正式的描述是：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

• Envoy的优点：
  • 开源，基于Modern C++11
  • 支持三层、四层、七层代理，支持http路由
  • 支持服务发现、健康检查。
  • 支持mongodb、dynamodb
  • 多种负载均衡算法
  • 动态配置。nginx并不支持哦。
  • 大厂开源google
  • 可以直接应用于kubernetes
  • 对于开发人员透明
  • 支持数据能正常收发层面的健康检查
    nginx注定了并不是service mesh的最好选择，因为envoy比它提供了更丰富的功能。不过依然可能会有很多公司使用nginx，因为nginx的运维技术相对成熟，网上资料大把。
    google、ibm公司还基于envoy弄了一套service mesh的框架Istio

• 参考
  什么是Service Mesh（服务网格） – 宋净超的博客|Cloud Native|云原生布道师
  RPC框架（一）RPC简介 – keep_trying的专栏 – CSDN博客