自己的狗食先吃_微服务的成熟度：教条或狗食？你决定…-CSDN博客

自己的狗食先吃

上周发布了关于微服务成熟度/分类模型的提案后，我收到了一些很好的反馈，有的是正面的，有的是负面的。

一些私人交流表明，我可能会陷入市场炒作，而几封电子邮件表明，微服务架构实际上只是重新发明的经典SOA。其他电子邮件通过建议微服务提供了一个学习和迭代SOA最初实现中所犯错误的机会来平衡这些评论，尤其是现在我们正在拥抱域驱动设计之类的概念，并且正在将更多考虑因素考虑在内，定义的软件体系结构。

到目前为止，我唯一看到的公开回应是我的伦敦微服务和Spring框架专家Russ Miles ，您可以在Simplicity Itself博客上阅读它。为了完全公开，我确实认识拉斯（并且在他的公司里喝了几口啤酒），但是这不会影响我认为对我的建议进行的精彩讨论。

成熟–并非全部...

Russ的第一条评论是，建立成熟度模型的方法可能很危险。我认为这是完全公平的，撰写第一篇文章时，我想了好几次。如此之多，我在标题上添加了“分类”一词，以替代成熟度。

如果您查看其他成熟度模型，例如API的Richardson模型或Continuous Delivery模型，则存在明显的规模感，从负到正。正如Russ正确地指出的那样，我的模型中尚有解释的余地，即较小越好，我可能应该多加注意，以表明我认为并非一定如此。

在某些情况下，单片但结构良好的体系结构可能是最佳解决方案。 Russ在最近的一次演讲中也猜到了Skillsmatter的观点，即从构建整体开始，然后转向微服务架构可能是构建软件最快的方法。很难通过轶事证据来证明这一点，但是我的直觉（和经验）告诉我，在某些情况下这可能是正确的，尤其是在目前我们对构建微服务的建模或工具支持几乎没有办法的时候。

在我看来，Russ认为可以否定地使用该模型是非常正确的，尽管我的初衷是给人们一个模型，供他们查看并指出他们认为软件的位置，但是它很容易被滥用。我希望获得更多有关如何塑造或发展模型以使我的意图更清晰的反馈。

大小–您要做的事情很重要（但大小仍然很重要）

拉斯还提到规模是危险的指标，我同意。尽管代码行（KLOC）可能是一个任意指标，尤其是在当前可用的多种语言和框架中，但我仍然相信大小很重要。不是从“如果您的应用程序超过100行，那就不是微服务”这种方式（公平地说，可以从我的模型中读取），而是从封装，责任感和理解的角度出发。

经过一番思考后，对于此概念而言，衡量体系结构/代码内聚性可能是一个更好的指标。我绝对相信微服务架构植根于高凝聚力（和松散耦合）的原则，但是西蒙·布朗（ Simon Brown）和鲍勃·马丁（ Bob Martin ）等人认为，微服务架构可以在整体代码库中实现，而无需创建单独的“服务”。这里的关键是模块化或组件化。

因此，我确实相信微服务的规模应该很小。对我来说，这是SOA原始方法的失败之一。缺乏熟练的建模和体系结构指导，使得服务可以转变为具有低内聚性的“所有唱歌和跳舞”应用程序。微服务提供的硬性系统边界（以及潜在的昂贵的协调和通信）与域驱动设计（DDD）中的“绑定上下文”概念结合在一起，对于开发人员来说，当我们在组件的职责范围之外走时，它应该变得更加明显。

传统SOA中出现的膨胀的供应商工具还允许开发人员通过规避诸如服务总线之类最初提出的模式和重量级ESB之类的怪诞事物的松散耦合来“欺骗”。这些天来，我们看到了工具的出现，这些工具鼓励基于小组件（例如非常有趣的AWS Lambda ）的React性系统和事件驱动的架构。对于AWS Lambda之类的服务，由于执行的性质，会强制执行代码库大小限制。看看哪些应用程序从这些框架中涌现将会很有趣。

在代码库上设置大小限制可能不是一门精确的科学，但我认为上限至少可以用作触发条件，以讨论服务是否正在超出其原始权限（或者架构质量是否下降）。我教给客户的很多敏捷和架构技术并不是确定应该做出哪些决定的严格规则，而是经常作为团队（或组织）进行对话或白板会议以检查是否要进行提示的线索我们仍在设计可正确建模业务的高质量软件。

教条或狗食-您决定…

拉斯发表的文章的最后部分包含最有力的论据，即关于思考的教条只会将我们引向错误的道路。如果可以的话，我想避免这种情况。” 是的，这很糟糕，但我同意。

问题在于我的学术背景使我趋向于在同龄人之间共享想法和建议，并且我喜欢随后的讨论。我们应该始终小心谨慎，以确保我们在这些讨论中保持务实态度（而不是“在餐桌旁解决世界上的问题”），但我仍然支持将内容发布给公众以征询意见。

拉斯还非常参考了格雷格·扬（Greg Young）去年在muCon上的演讲，这对于任何构建微服务的人来说都是必不可少的。他大规模地解释了Greg，他暗示微服务背后的许多概念以前已经完成，并且如果我们不小心的话，我们将重新发明轮子（尽管比以前更多的“微” :-)）。

格雷格（Greg）关于教条式标准化和过度选择供应商工具的负面影响的观察也特别令人发指，而且我在他的许多讲话中不禁点头表示同意（旁注，整个muCon会议很棒，并且我强烈建议您参加今年晚些时候的下一个迭代活动！Russ发起了本次会议，对他表示崇高的敬意）。

我绝对会注意避免成为教条（或鼓舞教条），但我仍然热衷于分享关于成熟度/分类模型的想法。事实证明，这种方法没有用，但过去几个月来，我已经与技术朋友一起使用了略微打磨过的该模型，以帮助他们了解当前软件堆栈相对于“诸如Netflix和Amazon之类的独角兽组织（还有什么技术专家会讨论一些啤酒！：-）。

我认为可以从这种建议中产生一些东西（可能更有价值），该模型可以向组织显示其软件处于创新，体系结构和交付的全局。该模型的每个级别还应该清楚地显示其优缺点，并提供有关组织为什么（如果有的话）将某些软件移至下一个级别的指导。我们还需要从务实的组织和文化角度（在实践中采用康威定律）以及从技术工具和流程角度来说明组织应如何做到这一点。

我目前正在阅读Jez Humble的新书《精益企业》，这为完成这些任务提供了极好的启发。我还在寻找一些新的模型和流程，一旦有了一些有用的见解，我就会确保我分享它们。