github上微服务

几周前，我很幸运能够参加出色的GOTO阿姆斯特丹会议 。 其中一条路是关于微服务的，自从我去年作为承包商工作的公司正在努力转向（微）服务架构时，我当然必须参加该特定路的大部分路线。

目前，围绕微服务的炒作正在肆虐，而且似乎每个公司都希望加入潮流。 随着Netflix一直被誉为成功实施微服务架构的公司的典范，很容易陷入陷阱，以为转向微服务架构将是小菜一碟。 甚至Netflix从一开始就没有做好，可能涉及很多试验和错误。

因此，我很高兴在GOTO阿姆斯特丹听到一些战争故事。 听取诸如弗雷德·乔治（Fred George），詹姆斯·刘易斯（James Lewis），雷梅尔特·皮特（Remmelt Pit），史蒂夫·贾德（Steve Judd）和塔雷克·阿贝德拉布（Tareq Abedrabbo）之类的声音时，他们在提供关于该主题的客观观点时非常启发。

这是我从会议上取消的一些前提条件，警告和指示，或者我去年亲身经历的一些前提条件，警告和指示。 它们没有特定的顺序，可以有些自以为是:-)

首先从整体开始

正如马丁·福勒（Martin Fowler）在他的博客文章中所建议的那样， Monolith First 确实从整体应用程序开始，甚至没有考虑微服务方法。 或者用他的《第一分配法则》来解释：“不要分配……除非您有非常有说服力的理由这样做。”

当然，仍然必须很好地设计和编码。 我非常喜欢Simon Brown直言不讳的方式：“如果您无法构建结构良好的整体，那么您认为您可以构建结构良好的微服务集是什么呢？”。

清楚地定义您的有限上下文

我发现明确定义的有界上下文对于任何体系结构样式都是绝对必要的，对于微服务而言更是如此。 不要只关注数据，规范数据模型等。 有限的上下文仅与您的业务域及其流程有关，而与数据结构无关 。 没有明确的界限，您很可能最终会遇到“分散的大泥球”。

确保避免跨上下文共享域库。

云基础架构和DevOps团队

微服务固有一个非常复杂的基础架构。 如果您的组织未使用云或容器化（Docker）基础结构，并且未在DevOps团队中进行结构化，但仍在使用数据中心或基于VM的基础结构，并拥有专用的OPS团队，那么甚至不考虑迁移到微服务架构。

解构数据库

在考虑微服务时，愿意解构数据库。 最后，您将获得大量的数据存储，通常每个服务一个，以及许多不同的类型（RDBMS，图形数据库，文档存储，内存键值映射等）。 确保您的DBA愿意放弃一个唯一的中央Oracle实例。

WTFM

正如Remmelt Pit在GOTO阿姆斯特丹会议上所说：“有了微服务，就没有RTFM，而是可以编写手册（WTFM）”。 从字面上看，您必须自己解决所有问题，并且基本上是从头开始。 关于框架和工具，尚无实际标准。 您仍然必须考虑和实施诸如监视，日志记录，生命周期管理，外部化配置，处理故障，进程间通信，端到端2测试等问题。

无论您将使用什么框架和工具，都可以使一切自动化！

翻译自: https://www.javacodegeeks.com/2015/07/dont-jump-on-the-microservices-bandwagon.html

github上微服务