IcyFenix
IcyFenix
> ”JKWS 顾名思义就是一组 JWK 的集合，支持 JKWS 的系统，能通过 JWT 令牌 “ 这里的JKWS是不是JWKS？ 感谢，已更正。
> 这点决定了可以很容易区出分冷数据和热数据 谢谢，已修正
> “这两种聚合方式都有不少实际应用，前者一般用于应对即席查询，后者用于应对固定查询” 中 “即席查询”应该是“即时查询”吧 即席查询，Ad-hoc search
> @dengchaoh > 在互利网中，面向资源来进行网络传输是这三十年来HTTP协议精心培养出来的用户习惯。 > 周大哥，“在互利网中”是笔误，“在互联网中”？ 感谢！已修改，下次commit时更新
> @UUNNFLY > 周老师，对于返回{code: xxx, message: "xxx", data: xxx}这种设计如何看待？是否是违背了RMM第2级的使用HTTP协议的Status Code，因此是RMM 1级？ 这种与REST谈不上有什么关系，最初的源头是JSON-RPC协议，但JSON-RPC Specification中也只是规定了在error中带code和message，现在有不少程序，包括一些较为有名的产品都发展到凡是交互就必定返回个code的程度。我个人不太感冒，但确实是很普遍的现状。
> 将“REST 与 RPC 在思想上差异的核心是抽象的目标不一样，既面向过程的编程思想与面向资源的编程思想两者之间的区别。”后半句中的“面向过程的编程思想”和“面向资源的编程”位置互相调换一下会不会好一点？第一次读到以为 REST 是“面向过程”，RPC 是“面向资源”，这和上一章的理解产生了偏差。 有道理，已修正
> POST /appointmentService?action=comfirm HTTP/1.1 > > 应为confirm 已修正，感谢。
> @manyouying > 需求场景->目标二的`在命令式编程的支持下`，应该改为在声明式编程的支持下吧 感谢指正，已更新。
> @allenz92 > > @wangpiju > > unable to recognize "https://raw.githubusercontent.com/fenixsoft/microservice_arch_kubernetes/master/bookstore.yml": no matches for kind "Role" in version "rbac.authorization.k8s.io/v1beta1" > > > > > > 我遇到跟你一样的问题， 你解决没有？ 现在版本的k8s的role和rolebinding已经不在v1bate1了，改到了v1组上，将bookstore.yml中的“rbac.authorization.k8s.io/v1beta1”修改为“rbac.authorization.k8s.io/v1”
> @UUNNFLY > VXLAN中MAC地址是出现两次吗？一次是最外层的Outer MAC Header，一次是里面的原始数据链路帧。这两个MAC地址是一样的吗 绝大部分情况都不一样呀，MAC的地址的作用是供二层交换机确定下一条（Next Hop）的机器位置，每经过一次网络跳点就会改变一次的。