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
- 即读写分离，这两个动作分别对应不同的数据结构