AB Data

有许多技术选项可用于实现单个微服务以及分布式系统的开发和操作的其他必要答案。然而，具有可维护性、可扩展性或可伸缩性等特性的优秀软件不能仅通过技术来实现。这个声明当然不具有革命意义。由于围绕微服务出现了大量的技术发展和框架，因此存在忽视基本问题的风险。因此，这篇博客文章的标题旨在作为提醒和基础：微服务只是创建了与单体应用不同形式的技术和概念债务。

微服务代表了一种架构模式，它独立于我认为的软件开发中最困难但也是最增值的任务：通过软件对真实现有信息和流程进行映射和正式结构化。在软件开发过程中，我们为这些信息和流程创建概念模型，并用编程语言等进行描述。优秀软件的上述特征很大程度上受到模型的选择性和定义的影响。模糊分解会创建模糊模型，从而导致软件各部分之间的紧密耦合和许多依赖性，或者软件各部分之间的许多不需要的冗余。结果，软件的质量降低，可扩展性降低，并且更难纠正编程错误。

根据架构的不同，依赖关系和冗余的表现也不同：在单 购买减肥信息 体架构中，我们会看到过时的代码、循环依赖和大量的跨模块调用，而在微服务架构中，功能重叠，会出现不必要的许多微服务。或者微服务包含对其他微服务不必要的理解，从而产生紧密耦合。

新的架构答案选项
无论软件开发和软件在其生命周期中的处理存在这些基本挑战，微服务都扩展了架构解决方案的工具箱。但是，就像任何技术创新一样，它们并不代表更好的软件的答案，更有趣的问题是它们是否还提供了其他层面的补充，例如软件开发方法。微服务对软件开发流程和软件交付流程有什么影响？微服务架构中强大的物理解耦是否也会影响交付、开发、测试和运营需求的团队的行为和心态？肯定是这样，但是怎么办呢？最后，技术隔离会导致消极意义上的团队隔离，还是会导致积极意义上的基于分离的定义的遵守？

微服务和拉锯战
Bradley 等人（参见《团队规模谬误：低估较大团队的效率下降》、《组织行为和人类决策过程》、Bradley R. Staats、Katherine L. Milkman、Craig R. Fox）研究了人群规模变化如何影响团体成员的行为。结果是：小团队中的人比大团队中的人更用力地拉绳子。当然，拔河比赛并不完全可以与软件开发学科相比，甚至更不能与可行概念模型的开发相比。我很想知道软件开发的实验结果会是什么样子，哪些企业文化和组织机构不仅可以通过微服务获得新的架构模式，还可以提高其软件交付效率。

结论
我们经常讨论软件开发中的技术和模式。通常还涉及开发过程的方法和组织方面，例如敏捷软件开发。在我看来，这两个方面的相互作用是为技术和软件开发方法之间的研究人员和有远见的人提供许多未来活动领域的问题之一，以激发优秀软件的开发。你们都是什么意思？

托马斯·弗朗茨图片
作者 博士。托马斯·弗朗茨

博士。 Thomas Franz 是 adesso 的技术专家。他对大数据、精益创业和 DevOps 等主题以及它们与 NoSQL 数据库、云基础设施和现代 Web 架构等技术趋势的互动感兴趣。