F周刊：2017-02-11

Evolving Distributed Systems

很喜欢文中介绍的SCS（Self-contained System）概念，事实上，个人认为很多其他文章/书籍中提到的微服务其实叫SCS更合适。

正如作者所说，微服务这个词暗（鼓）示 （励）设计者把系统划分得越小越好。但系统过度划分之后带来更多的交互，每个交互又意味着耦合，进而影响分布式系统中各组成部分的单独演变。无法单独演变，意味着无法单独部署。而这，又是微服务当初鼓吹的优势之一。通过引入SCS，消除了不必要的内部交互。

对于SCS之间的交互（往往是REST服务），作者建议使用超媒体，并且介绍了客户端正确打开REST响应的姿势：关注link胜于关注属性，同时这也是HATEOAS的关键。相比之下，关注link的客户端更智能，耦合度更低，更利于通信双方的独立演变。

关于超媒体，文中自带的这两个链接也值得一读，让我对这个概念有了更深刻的理解：

• The Benefits of Hypermedia APIs
• What is a Hypermedia client?，大部分文章大谈服务器如何产生超媒体，而这篇文中则着眼于客户端如何对待超媒体，可以帮助开发者理解REST的魔法。

Why Hollywood as We Know It Is Already Over

在未来，可能是AI助手为我们定制视频，合成演员；我们则通过VR/AR跟异地的朋友一起在虚拟的剧场里观看。这预示着一堆职位的消失——编剧、剪辑、导演、甚至演员——而这些人最初都认为“我们是特别的，无可替代”。

历史已经告诉我们，技术的变革之下，没有人是安全的，唯一不变的是生意，改变的只是做生意的方式。这一切正在好莱坞发生，虽然它还会在哪里，但已经不是我们认识的好莱坞了。

Comparing Container Orchestration

目前容器协调工具的的巡礼，最吸引我的还是Nomad，不仅仅鉴于其轻量级（可直接支持Jar），而且还因为可以跟其同族的好兄弟们，如Consul，一起协作。

How I Rewired My Brain to Become Fluent in Math

仅仅只是“理解”，还不足以让知识成为你的一部分，这种“掌握”的假象会随着时间的流逝得以暴露。不断实践、重复练习，直至熟练，真正的“理解”才会真正的到来。这倒符合古人说的：书读百遍其义自现。

整个文章的真意跟我目前看的《刻意练习》有几分相似，通过不断练习，构建适合自己长期记忆的神经链路，让知识在一种更高层面有机的组织起来，不再是零星的知识点。这样的组织形式在实际应用时可让人成为所谓的“专业”选手。

说穿了，还是那句：熟能生巧。

Vert.x 3.4.0.Beta1 release

Vert.x最新的beta版本周发布了，按开发者的说法，该版本是3.0发布以来最大的变化。最让我关心的就是CB和Ignite不再是技术评估版本，最让人觉得有趣的就是Web Client。

以社交活动的方式做计划-乐高公司的规模化敏捷

早些年，很多人认为敏捷只适用于小团队。这些年，公司若不宣称自己也在采纳敏捷都不好意思出门。虽然这样，很少看到那些大公司分享自己的“敏捷之道”（或许是被我无意识忽略了）。申导翻译的这篇乐高的文章让我们得以一窥大规模敏捷的实施一角。

文中两点让我印象深刻：

• 参与者的勇气，只问效果，不拘于泥过程
• 自下而上和自上而下的相互作用最终推动了组织内的变革，这不正是“上下交而其志同”的真实写照吗？

论微服务安全

数人云在SF上的专栏，一篇不错的微服务安全入门资料。

What do you mean by “Event-Driven”?

• Event Notification
  • Source不关心Response，不适用于有较为复杂交互的场景
  • 建议：Event Message携带少量数据和Source ID，待Receiver收到之后，主动决定是否找Source，典型如变化通知
• Event-Carried State Transfer
  • 适用于Source状态需要同步，且多地保留副本的场合，典型如不同微服务之间共享数据的本地副本
  • 复杂性在于多副本的协调和同步
• Event-Sourcing
  • 变化以Event Log的方式记录，通过重放Event Log的方式可以重建状态，典型如Git版本库
  • 注意区分：工作副本、快照和Event Log的区别，并非所有处理都需要从Event Log重建直到当前状态
• CQRS
  • 即读写分离，这两个动作分别对应不同的数据结构