微服务和比特币:阿姆斯特丹笔记


几周前我参加了GOTO Amsterdam conferenceBeautiful venue,很棒的食物,但最重要的是,几个有趣的演讲吸引了我的注意。在两天和五到六首曲目中,我想评论几个环节。

"Challenges in Implementing MicroServices"Fred George

你可能会说,这是另一场微服务演讲。但这一次稍微深入一些,也更实用一些。[幻灯片可用],让我评论一下幻灯片10,复制到这里:


微服务原理综述

  • 非常非常小
  • 需要开发/维护的团队规模只有一个
  • 松耦合(包括流)
  • 可以接受多个版本吗(鼓励?)
  • 每项服务的自我监控
  • 发布有趣的“材料”(无明确要求)
  • “应用”似乎是一个糟糕的概念化概念。

我不太相信“微“甚至”纳米“服务趋势。服务不应该越小越好,它应该封装业务组件,通常bounded context。如果它只是一个有限制的上下文,那么它就是微服务。从性能的角度来看,任何较小的东西都是不实用的(协议太冗长,延迟太大)。我也不认为一个团队显影剂就足够了。优秀的团队有5 people +/- 2,包括QA、PO等,但为了进行任何结对编程、代码审查、改进bus factor-您需要不止一个开发人员。我同意这张幻灯片的睡觉,整个演讲真的很酷。我特别同意出版有趣的书。东西*。即使没有微服务,我们也知道集中式共享数据库是不好的。事件存储保持业务事件的长历史(例如Kafka)通常可以解决服务之间共享数据的问题。有趣的是,它允许我们启动需要大量资源的新项目(所有?)来自其他项目的历史数据,无需成本高昂的数据迁移和批处理作业。只要抓住历史事件,你想要的深度就有多深。警告:确保您的分布式事件存储不会成为另一个集中式“数据库”。否则,有一天醒来时,您会发现系统以与昨天略有不同的格式发布事件,破坏了太脆弱的消费者。

我完全同意弗雷德的观点,异步通信应该是首选的。就像发布事件一样,通过消息传递进行通信可以实现更好的解耦和弹性。有一个地方可以阻止通信:在处理在线请求时,或者现在需要数据时,或者永远不需要数据时。但专注于信息传递将是有回报的。

"How the Bitcoin Protocol Actually Works"Jan Møller

令人惊讶的是,简·穆勒在50分钟内成功解释了比特币协议/货币是如何运作的。我在完全没有任何先验知识的情况下参加了那次会议,但离开时我很好地理解了协议是如何出色地设计出来的。以我拙见,最好谈谈。请查看[The slides(http://gotocon.com/dl/goto-amsterdam-2015/slides/JanMller_HowTheBitcoinProtocolActuallyWorks.pdf),]我甚至不想总结我所学到的内容,而只是给您一个快速的概述。比特币协议背后的核心理念是blockchain-不可变的、全局的、仅附加的事务列表。比特币网络中的节点可以添加到该列表中,以确认交易。

在这次会议中,我了解了:交易是如何被接受的,为什么可能需要几分钟的时间,为什么挖掘过去是有利可图的,矿工现在如何从交易费中获利,在参与节点数量未知的情况下,算法设计是如何控制挖掘速度的,甚至还了解了哪些是最受欢迎的攻击,它们被规避了。精彩的谈话,简真的知道他在说什么。

我还想提一下"The Evolution of Hadoop at Spotify - Through Failures and Pain"Josh BaerRafal Wojdyla非常有趣。这些人构建了一个令人印象深刻的Hadoop集群,并分享了他们的知识和经验,例如如何监控全公司范围广泛的开发人员开发的作业。不过,我有点担心Map-Reduce概念的“未来”。谷歌published the idea在2004年和abandoned this concept2014年-我们是否选择了Hadoop?我想要的另一个演讲链接是"Developing Event-driven Microservices with Event Sourcing & CQRS"Chris Richardson-我不能参加那个活动,但是slides看起来很有前途。

总体而言,我喜欢前往阿姆斯特丹的会议,非常感谢4Finance IT感谢你赞助这次旅行。