Algorithm：
643: Maximum Average Subarray I
correct before optimize
先能正确的写出来，不要一开始想太多，比如这一题，因为思路简单，一开始就想着只用一个循环和如何精简合并分支条件，结果边界条件混乱，多次失败才过...当然，最后看答案这里可以不用双指针思想，用滑窗的思想，两个位置分别是 i 和 i - k，也很巧妙。
public double findMaxAverage(int[] nums, int k) {
int sum = 0;
int i = 0;
while (i < k) {
sum += nums[i++];
}
int max = sum;
while (i < nums.length) {
sum += nums[i] - nums[i - k];
max = Math.max(max, sum);
i++;
}
return 1.0 * max / k;
}
Review：
Taming Service-Oriented Architecture Using A Data-Oriented Service Mesh
来自 Airbnb 的 Service Mesh 框架 Viaduct 技术分享，首先他们提出了标准的 sevice mesh 依然有 microservices 或者更普遍的 SOA 架构的依赖复杂问题，他们类比 spaghetti code 将其称作 spaghetti SOA，解决办法是类似从面像过程调用（API调用）的程序设计，转变为面向数据的程序设计方法（主要是面向对象），将面向过程的 service mesh 转变为面向 data 的形式。
具体来说一个服务定义就是一个 GraphQL schema 定义，包括 Types、Querys、Mutation 几部分（GraphQL 术语），比如查询一个商品及相关连评论信息，只需根据 schema 使用 GraphQL 表达式查询即可，由 Viaduct 即他们的 service mesh 向具体多个服务提供者进行调用和拼装处理。
这种 service mesh 带来很多可操作空间，比如他们针对无状态的派生数据（derived data）服务和 BFF 服务（面向前端的后端服务层），将他们以 Serverless 形式部署为 cloud functions 供 Viaduct 访问（作为 schema 中的 derived fields），这也又衍生出更进一步的形式 - 中心化 schema 管理，将服务域中的所有 schema 统一集中管理，并以此构建新的 service APIs 和 database schemas，这可以尽量减少微服务中某一数据库表变化导致一系列依赖团队协调配合的问题，因为 schema 集中管理并由 Viaduct 组织，可以使数据层变化更加敏捷。
最后，Viaduct 是由 graphql-java 扩展而来，可以利用 GraphQL 开源生态中大量已有东西。而这篇文章也是基于他们在 GraphQL 会议的分享而来，可以说是 GraphQL 的一次推广。
另外我对 graphQL 的初次理解：一种比 Rest 更加高级的 API 形式，用官网的话说是 A query language for your API，其优势在于向更加关注数据组织而不是如何定义接口、一次请求多个资源由服务端组织后一次返回、高级和可扩展的类型系统、跨语言和工具丰富等。
Tip：
Prometheus 的 pushgateway 问题总结
在实践 pg 的过程中发现一个严重的问题，不同机器上报的 metric 会相互覆盖！具体来说就是不同机器实例 push 同一个 name 的不同 label value，在 pg 上看只有最后一次上报的数据，也就是每次 push 都会覆盖之前其他机器上报的。这导致所有机器的 tps 指标汇总后严重偏小，即只有一台机器时正常，部署机器越多越偏小。
首先再仔细看看 pg 的上报 api 发现除了 push 还有 pushAdd、del 这些，根据文档说明，push 会调用 http put 以这次推送为准覆盖所有指标（幂等性），而 pushAdd 是调用 http post 请求，会覆盖相同 name 的指标，不同 name 的不会被覆盖，这和我的问题不太匹配，我想要相同 name 不同 label value 的也不覆盖，随手试一下改成 pushAdd 后果然没有效果。
继续调查发现是我对 pg 的理解还有偏差，它的设计意图是用作临时任务的上报，并且以 push 参数中的任务名称 - 即 job name 为维度进行上报，因此相同 job name 的 push 其实都会被覆盖，而解决办法就是把 job name 上追加机器实例信息，如 ip + pid，这时调用 push 或是 pushAdd 也没有区别，我是后台线程进行定时 push，这么修改后问题也就解决了。
最后还有一些细节，这些 job name、instance id 等在 prome 中都是作为 label 存储，因此也可以方便地以 metric name 汇总。额外的，它还有个 grouping key 的概念，也是 push 时的可选参数，会在 pg 上以它为单位产生 job name 后的细分维度，也是正统的解决 job 相互覆盖的方法。比如我的例子中就是用 ip 和 pid 这两个原来已有的 label 作为 grouping key，但是测试时发现它似乎有个 bug，即原来没有 grouping key 的 job 如果增加 grouping key 后，或一开始就有 grouping key 的 job 去掉 grouping key 之后调用 push 会返回下面异常（一开始就有 grouping key 再修改则没有问题）。相比之下修改 job name 后缀则不会有这些问题，而且我这里 job name 对业务没用可以随便修改。
http code 400:
pushed metrics are invalid or inconsistent with existing metrics:
xxx was collected before with the same name and label values
最后的最后，现在这样上报也会有 pg 上的数据只增不减的问题，似乎是官方设计如此，需要自己手动调用 del api 进行删除，这个后续可能需要做一个对 pg 过期清除的定时任务。
<JOB_NAME> is used as the value of the job label, followed by any number of other label pairs (which might or might not include an instance label). The label set defined by the URL path is used as a grouping key. Any of those labels already set in the body of the request (as regular labels, e.g. name{job="foo"} 42) will be overwritten to match the labels defined by the URL path!
https://github.com/prometheus/pushgateway/blob/master/README.md
Share：
一份致某科学院的报告
https://www.williamlong.info/book/archives/389.html
这是卡夫卡写的一篇有趣的短篇小说，在文中以一只猴子的口吻描述了自己的经历：从它被人类捕获，被关在笼子里失去自由并痛苦不堪，进而开始以模仿人类作为出路，付出极大的努力、学会人类说话直到最后达到一般人文化水平并进入人类社会的经历。
文章的一个主题是自由与出路，正如一开始它身处狭小的铁笼中，站不起来也坐不下去，后背嵌入栅栏之中，它感慨以前是多么神通广大，而现在却穷途末路，寸步难行。它说自己不要求自由，当时没有，现在也没有，只要一条出路，只要是不是关在这样的笼子里就行。逃跑不是出路，虽然它可以咬断笼子逃出去，去追求无拘无束自由，但是结果也不能逃到哪里去，最终只能葬身大海。它选择冷静下来，也正是这份平静和观察，让它逐步明白在人类社会出路只有一个，那就是变成人类。它提到模仿人类对它并无吸引力，只是为了寻找一个出路罢了，后面也提到学习也是出于迫不得已，想找条出路（为了进入马戏团和避免进入动物园）。最终的结果我们知道了，它实际上获得了自由，正如它说 “自由是人类最高尚的情感，与之相应的幻觉易属此列“，人类社会中却有无数人打着自由的口号招摇撞骗，让人反思自由到底如何追求？
文章的另一个主题是固执与开化，它把力克固执作为最高信条，“不再抱着本族的本性和少年时期的回忆，让过去之风越来越微弱”。在导师的帮助下，不懈地与猴子的本性斗争，比如文中一系列描述：克服难受、极度渴望、精疲力尽、用鞭子鞭策、聘请更多老师等，最终猴子的本性迅速排除，知识之光照进了开化的大脑，它感到了幸福，不仅走出了牢笼，也开辟了新的人生之路。
正如卡夫卡著名的《变形记》中人变虫，在这篇中是猴变人，但是忽视变形这一荒诞的设定外，变形记关注的是现代人类的异化，这篇关注了进化。其中猴子与人类、自由与出路、固执与开化，这些对比非常引人深思。