几周前，我参加了 GOTO 阿姆斯特丹会议 。 美丽的场地 ，美味的食物，但最重要的是，一些有趣的谈话引起了我的注意。在两天的五到六首曲目中，我想评论几个会话。
Fred George 的 “实施微服务的挑战”
您可能会说，这是另一个微服务话题。但是这个稍微更深入和实用。 [幻灯片可用]，让我评论幻灯片 10，复制到这里：
微服务总结原则
- 非常非常 小
- 一个 开发/维护的团队规模
- 松散耦合（包括流）
- 可以接受多个 版本 （鼓励？）
- 每个服务的自我监控
- 发布有趣的“东西”（没有明确要求）
- “应用”似乎是一个糟糕的概念化
我不太相信“ 微型”甚至“纳米”服务趋势。服务不应该越小越好，它应该封装业务组件，通常是 bounded context 。如果它只是一个限界上下文，那么它就是一个微服务。从性能的角度来看，任何更小的东西都是不切实际的（协议太繁琐，延迟太大）。我也不认为 一个 开发人员团队就足够了。好的团队有 5 人 +/- 2 ，包括 QA、PO 等。但是为了进行任何结对编程、代码审查、提高 总线因素 ——你需要不止一个开发人员。我同意这张幻灯片的其余部分，整个演讲真的很棒。我特别同意发布有趣的 东西*。即使没有微服务，我们也知道集中式共享数据库是不好的。保存业务事件长期历史的事件存储（例如 Kafka）通常可以解决服务之间共享数据的问题。有趣的是，它允许我们启动需要大量（全部？）来自其他项目的历史数据的新项目，而无需昂贵的数据迁移和批处理作业。简单地抓住历史事件，只要你想深入。警告：确保您的分布式事件存储不会成为另一个集中式“数据库”。否则，有一天您会发现系统以与昨天略有不同的格式发布事件，破坏了过于脆弱的消费者。
我完全同意 Fred 的观点，应该首选异步通信。就像发布事件一样，通过消息传递进行通信可以实现更好的解耦和弹性。有一个地方可以阻止通信：处理在线请求时或现在或永远不需要数据时。但专注于消息传递会有所回报。
Jan Møller 的 “比特币协议实际上是如何工作的”
令人惊讶的是，Jan Møller 在 50 分钟内成功解释了比特币协议/货币的工作原理。我参加那次会议时完全没有任何先验知识，但对协议的设计有多么出色有了很好的了解。以我的愚见最好的谈话。查看[幻灯片(http://gotocon.com/dl/goto-amsterdam-2015/slides/JanMller_HowTheBitcoinProtocolActuallyWorks.pdf)，我什至不想总结我学到的东西，只是为了让你快速了解一下寻找。比特币协议背后的核心思想是 区块链 ——一个不可变的、全局的、仅附加的交易列表。比特币网络中的节点可以附加到该列表，确认交易。
在本次会议中，我了解到：交易如何被接受以及为什么可能需要几分钟时间，为什么挖矿曾经有利可图以及矿工现在如何从交易费用中获利，算法设计如何在参与节点数量未知的情况下控制挖矿速度，甚至是最流行的攻击是什么，它们都被规避了。迷人的谈话，简真的知道他在说什么。
我还想提一下 Josh Baer 和 Rafal Wojdyla 的 “Hadoop 在 Spotify 的演变——通过失败和痛苦”， 非常有趣。这些人构建了一个令人印象深刻的 Hadoop 集群并分享了他们的知识和经验，例如如何监控整个公司范围内的开发人员开发的作业。然而，我有点担心 Map-Reduce 概念的“未来”。谷歌在 2004 年 发布了这个想法 ，并在 2014 年 放弃了这个概念 ——我们用 Hadoop 赌对了马吗？我想要链接的另一个演讲是 Chris Richardson 的 “使用事件源和 CQRS 开发事件驱动的微服务” ——我没能参加那个演讲，但 幻灯片 看起来很有前途。
总的来说，我很喜欢 GOTO 阿姆斯特丹会议，非常感谢 4Finance IT 赞助这次旅行。