上周，我谈到了作为一系列微服务开发的产品技术架构。谈话几分钟后，很明显团队已经支付了微服务高级版，但没有明显的投资回报。这组微服务是由一个由10名工程师组成的团队构建的，所有服务都是用java实现的，并使用消息总线将必要的数据复制到共享postgres实例中的自己的模式中。虽然工程师可能最有意愿建立一个可以扩展的系统，但它立刻让我想起了Donald Knuth的名言，

过早优化是万恶之源

我认为团队会更有效率，如果系统被构建为具有良好模块性和服务之间松散耦合的整体系统，那么系统就不那么复杂了。

让我们看一下微服务架构的优缺点，从我自己的经验来看，我在SAP时为我们构建的产品采用了微服务架构。

释放灵活性

采用微服务使我们能够灵活地根据微服务中代码的成熟度和质量来决定哪些功能可以通过v1发布。另一方面，单片应用程序意味着延迟发布，直到我们把所有事情都弄好。

主题移交

虽然我不是世界各地分布式团队的忠实粉丝，但我们需要接受并继续前进，这是今天的商业现实。通过遍布三大洲（美国，德国和印度）的全球开发团队实施产品非常具有挑战性，但在微服务方面明确分离功能使我们能够灵活地在不同地点之间移动功能。由于团队不需要了解整个代码库以详细了解功能集的一小部分，因此主题切换非常易于管理。

规模

扩展单片应用程序（尤其是水平扩展）绝对是可能的，但并非应用程序的所有部分都可能从扩展中受益，因为吞吐量要求因产品的不同功能而异。微服务架构允许我们根据吞吐量要求扩展应用程序的不同部分，并有效利用可用资源。

自治

我非常相信团队的完全自主权，这与微服务架构相得益彰，因为团队之间的依赖关系减少到最小，并且通过定义良好的接口或API进行通信。团队完全自治的缺点是编程语言，框架，开发工具的动物园，一旦团队扩展到100人，就变得无法管理。虽然微服务架构鼓励多语言运行时，但我建议坚持几个运行时，几个框架以及一个基于一个工具集的构建和发布过程。

监测和支持

由于微服务按照定义分布在许多服务器（物理或虚拟）上以实现水平扩展，因此它们运行的平台应提供强大的监控和支持基础架构。监视和支持在调试和查找日志文件中的错误的根本原因方面由于缺少聚合每个产品的日志和跟踪文件的工具而变得非常麻烦。例如，支持工程师可能需要查看每个微服务的大量日志文件，以找出错误的根本原因。

构建和发布

在微服务部署的情况下，构建和发布过程的复杂性有时会使团队士气高涨，因为他们不断与构建作业和部署作业作斗争。对我们来说，缺乏构建，部署和发布自动化是一项挑战。照顾一个构建工作，一个代码扫描，每个服务就像放牧猫一样。如果有什么东西打破没有人通知。事实上，我们每个微服务都有多个构建作业 - 一个用于拉取请求，一个用于运行代码扫描和集成测试的主构建，另外一个可以发布到工件库中。完全自动化的构建和发布过程是微服务架构有效提高开发人员工作效率的关键。

安全

在微服务架构中获得安全性是一个真正的复杂性助推器。我们花了很多时间来确定基本的安全要求，例如身份验证和授权（特别是在服务到服务通信上下文中），因为每个微服务都运行在它自己的进程中，而不是整体结构。使用单一应用程序，处理安全性就像将spring安全库放入Web应用程序，创建spring-security.xml并向REST端点添加一些安全注释一样简单。使用微服务，使用JWT处理复杂的OAuth流并在服务之间传递令牌并非易事.

数据复制

最后，我认为在微服务方面最重要的权衡是关于是否复制数据的争论（特别是在大数据环境中）。关于如何复制数据的技术 - 消息总线，点对点REST API等是这个决定的简单后续。

通常，为微服务（有界上下文）获取服务边界非常困难。如果服务边界不正确，则会导致数据重复并增加服务之间的耦合。数据重复是一个很大的问题，特别是当微生物主要是分析性的并且需要依赖于或多或少相同的大数据集进行分析时。

在大数据分析环境中，我不是复合服务或复合API的忠实粉丝（我将其定义为需要处理大约数百万个数据点以满足请求 - 如排序，过滤）。复合REST API实现往往性能较慢，无法与DB的响应时间相匹配，DB是处理连接，聚合，过滤等事情的理想场所。

我们最终创建了一个数据服务，它创建了一个像依赖的平台，因为几乎所有其他微服务都依赖于这个服务来查询大数据集。必须在此层中实现任何新查询，这会降低新功能的开发速度。但查询响应时间对于应用程序来说至关重要，因此我们可以进行权衡。

生存还是毁灭 ！

与所有软件架构一样，为您的产品采用或不使用微服务是一种权衡讨论和决策。