小团队如何以“正确的方式”设计微服务架构？

聊聊架构 · 公众号 · 架构 · 2018-07-29 10:07

正文

请到「今天看啥」查看全文

接下来，Bryzek 提出了一系列对微服务的常见误解。第一个误解是“微服务能够让团队选择符合他们任务的编程语言和框架”。而实际情况是，这可能需要付出很高的代价，为了在技术栈中支持额外的开发语言，团队规模和投入成了关键的输入。

如果我们将 Google 视为一家优秀的工程公司，他们拥有大约 20,000-30,000 名工程师，使用了至少 8 种编程语言。那么可以说，每 4000 名工程师采用了一种编程语言。

第二个误解是“代码生成是邪恶的”。而现实情况是，“定义 100％受信任的模式”对于资源和事件来说非常重要，因为这个时候生成代码对于扩展开发和维护工作来说非常有用。第三个误解，“事件日志一定是事实来源”，而现实情况是，事件是接口的关键部分，但“将服务作为资源的记录系统是没有问题的”。最后一个误解是“每个开发人员维护的服务不应该超过三个”，在实际当中，这个数字可能是错误的。Bryzek 表示，这是“自动化发挥作用”的地方，Flow.io 的开发人员每人维护大约五个服务，每周用于维护的时间不到 5％。

接下来，Bryzek 介绍了 Flow.io 的架构。他们的架构使用了基于 JSON 的面向资源的 API 模式，可以对实体和相应属性进行定义，并带有适当的元数据。模式定义文件保存在 Git DVCS 中，并启用了持续集成。他们通过一系列测试保证整套 API 的一致性，并将这些测试作为高级的 linter。这些测试的目标是让工程师相信“整套 API 是由一个人写出来的”。