微服务架构需要考虑（新项目要不要用微服务架构）

：暂无数据 2026-09-04 19:30:02 ：0

其实微服务架构需要考虑的问题并不复杂，但是又很多的朋友都不太了解新项目要不要用微服务架构，因此呢，今天小编就来为大家分享微服务架构需要考虑的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

本文目录

新项目要不要用微服务架构
微服务测试的思考与实践
微服务与分布式系统架构问题如何解决
Java互联网架构-微服务架构如何解决跨库问题的思路与方案

新项目要不要用微服务架构

文中提及了两个现象：

其实文章中也大致归结了原因，有两个：

最近负责了一个相对复杂的产品的设计，从一开始的设计原则就是：「面向未来服务拆分构建单体应用」，所以在最一开始结合产品功能进行和模块划分以及拓扑设计，按照如下规则：

当时考虑的点如下：

鉴权通过中间件实现，后续拆分成微服务之后，需要进一步前置到 Gateway，减少 Auth 服务的请求次数，因为该服务是整个系统最关键且不可降级的部分，所以需要尽量减少压力

除了上述限制以外，还引入了 Protobuf，吐出数据给客户端以及日志都会采用 pb 进行序列化，好处是方便字段管理，同时 pb 兼容生成 json，顺便也能降低书写成本，不用写一堆 json:"xxxx" 的 struct tag 。

文章随后又说到了从头构建系统的四种套路：

提到的第一种就是我这个项目提到的方法，但是随后 martin 说了一句：

嗯，其实就是他是对这种方案没有信心的，注释中提到因为他觉得不是任何一个系统都能拆分成微服务，这种上来就假设拆分成微服务的思路是有问题的。

当然啦，为什么我却用了这种方法呢，其实是因为我明确的知道这个系统可以拆分成微服务，基于经验。

当我们接触到一个自己并不是非常熟悉的系统或者领域的时候，确实不能在假设可以拆分成微服务的前提下，去设计系统，万一未来不能很好的划定边界，提早的拆分其实会给以后的灵活性大打折扣。

综上，新建立一个系统的时候，最好的方式不是从微服务开始，原因如下：

微服务架构本身是一件奢侈品，本身会带来的在研发，管理的成本就很高，应该把他作为团队逐渐变得非常复杂后，不得不考虑的一种架构方案，而不应该作为 start up 项目的推荐方案。

为什么说是「团队逐渐变复杂」而不是「系统逐渐变复杂」呢？因为如果是系统逐渐变复杂的情况下，无论是单体还是微服务，都需要你对于边界有个相对清晰的划分和理解，此时单纯的引入微服务架构，并不能解决根本的问题。只有当团队逐渐变复杂之后，微服务架构更多是通过服务之间物理上的隔离，提高了团队将整个项目变成大杂烩的门槛。

首发于 Medium： engineer-alex

微服务测试的思考与实践

最近几年，微服务架构越来越火爆，逐渐被企业所采用。随着软件架构的变化，对应的软件测试策略需要作何调整呢？本文将介绍微服务架构下的测试策略，并结合分享在业务和架构演变过程中，一个历经九年的项目测试策略的演进。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体的业务进行构建，并且能够被独立部署到生产环境、预生产环境。

从微服务的概念可以看出它有如下好处：

同时，独立开发导致技术上的分离，HTTP通信加上Queue的机制增加了问题诊断的复杂度，对系统的功能、性能和安全方面的质量保障带来了很大的挑战。另外，服务间的复杂依赖关系带来了很多的不确定性，要实现独立部署，对运维也提出了更高的要求。微服务架构的系统要特别关注这几个方面：

谈到微服务的测试策略，很容易就想到了老马推荐的文章《 Microservices Testing 》，该文推荐的微服务框架下的测试策略是这样的：

（经典策略模型）

这个策略模型强调测试分层以及每一层的恰当覆盖，整体符合金字塔结构。它是最优的吗？

有人对此提出了质疑...认为策略模型应该是蜂巢形状的（请参考文章）：

（蜂巢模型）

这个模型重点关注服务间的集成测试，两端的单元测试和UI层E2E测试较少。

也有同事提出微服务下的测试结构应该是钻石形状的，服务间的集成依然是重点，单元测试较少，而顶层增加了安全和性能等非功能测试。

（钻石模型）

好像都有道理，到底选择什么样的策略模型好呢？不禁陷入了困境…...怎么办？不妨先来听听我们项目的故事吧！

还是那个蓝鲸项目，不知不觉进入了第九个年头。在这九年里，随着业务的不断发展，系统架构也进行了多次演进和调整。相应的，测试策略也发生了有意思的演进变化。

（测试策略的演进）

最初单一用户系统、单体架构的时候，严格按照测试金字塔来组织各层的自动化测试。随着功能的扩展，大量mock的单元测试给重构带来了很大的不便。

企业系统开始开发的时候，我们调整了策略，减少单元测试的编写，增加UI层E2E测试的覆盖，测试结构由原来的金字塔演变成上面梯形下面倒三角的形式。

后来，架构调整，开始服务化。此时，大量的E2E测试渐渐暴露出问题：

因此，项目引入契约测试，停止编写新的E2E测试，将测试下移，分别用API测试和契约测试取代。

随着功能的不断增加，虽然E2E测试的量并不增加，但是其不稳定性、维护难、定位难的问题有增无减，此时已经很难由自动化测试来保证产品的质量。为了平衡成本和收益，项目考虑去掉大部分E2E测试，只保留少量的Smoke测试，将更多的测试下移。

同时，技术雷达上新的技术“生产环境下的QA”出现，项目也开始关心生产环境，并且在QA测试阶段结合微服务的特点进行对应的探索式测试。

前文提到过微服务带来的挑战，下面来看项目是如何应对这些挑战的。

服务间的依赖、连通性

微服务架构下，独立开发的服务要整合起来最具挑战，如何保证服务间的依赖关系和连通性非常关键。前面已经讲过E2E集成测试有很大的挑战，并不适合，而消费端驱动的契约测试是个不错的选择。项目正是利用契约测试去保证服务间的连通性，取代一部分E2E集成测试。

服务的容错、可用性

在系统负荷达到一定程度或者某个服务出现故障的时候，微服务架构有两种技术来确保系统的可用性：服务的熔断和降级。服务的熔断是指当某个服务出现故障时，为了保证系统整体的可用性，会关闭掉出现故障的服务；服务的降级则是当系统整体负荷过载的时候，考虑关闭某些外围服务来保证系统的整体可用性。

对应的测试包括：

数据的最终一致性

（数据一致性）

数据一致性是微服务特别需要关注的。举个例子，电商平台某个订单支付成功以后，需要更新积分和订单状态，当订单服务或者积分服务其中有一个出现故障的时候，就会导致最终的数据不一致性。

测试这种情况，从业务的角度分析哪些服务会导致数据不一致性，制造对应的异常情况去测试数据的最终一致性。

独立部署

微服务的独立部署需要有CI、CD的支持，跟DevOps实践分不开。同时，更为关键的是需要契约测试来验证独立部署后服务行为的正确性。项目在这方面的工作，请参考王健的文章：你的微服务敢独立交付吗？

不确定性

微服务架构使得系统复杂度增加不少，很多的事情发生都是不可预测的，只能在其发生以后找到产生的原因。因此，也就没法在预生产环境通过测试去发现在真实生产环境才会发生的issue，我们需要把目光转移到生产环境，利用生产环境的不确定性、微服务的不可预测性来构建反脆弱的系统。

项目在这方面主要采用的技术是生产环境下的QA，请参考文章：生产环境下的QA

从前面介绍的演进过程可以看到，项目测试策略在不同阶段结合参考了不同的策略模型：金字塔-》近似钻石（除非功能测试外，类似于钻石模型）-》蜂巢。后期全面服务化的时候，我们认为蜂巢模型是比较适合的。

当然，光有符合这个策略模型的自动化测试是远远不够的，我们项目还采用了针对微服务特点的探索式测试，保持持续交付节奏，践行DevOps实践，结合生产环境下的QA等技术把关注点右移到生产环境。

现在，项目整体测试策略演变成下图的形式：

（项目测试策略）

项目上多次测试策略的调整，看似很简单，其实每次调整并不是一个轻松的过程，都是平衡利弊、综合考虑多个因素才做出的决定。

分析整个调整过程，最后突然发现：当我们面对多个策略模型不知道如何选择的时候，其实我们陷入了一个太过于关注测试结构的误区，忘记了最初的目标是什么。

跳出误区，回到原点，重新思考测试策略的目标。影响策略的最关键因素是业务价值、质量要求、痛点。

（影响测试策略的因素）

业务价值

带来更大的业务价值、帮企业赢得更多的利润，是软件系统的目标；软件测试是软件系统成功的保障之一，业务价值也是测试策略的终极目标。所有测试活动都要围绕这个目标开展，考虑业务优先级，有效规避业务风险。

质量要求

不同的系统、同一系统的不同利益干系人（参与的不同角色）对于质量的定义和要求都可能是不同的，这毫无疑问是影响测试策略的一个关键因素。

对于仅有内部用户的系统，关注的重心可能是系统的功能；而对外发布的产品，则要求更高，一个按钮位置的不恰当都可能带来大量用户的流失。

痛点

真正的痛点往往也是优先级最高，迫切需要解决的。那些可以通过测试策略的调整来解决的痛点，自然成为了关键的影响因素之一。比如，CI Pipeline出包太慢，为了提高出包的效率，一方面在Pipeline本身想办法，另一方面调整自动化测试的比例、执行频率等也是解决方案之一。

处在不同阶段的项目，在业务价值这个大目标下，其他影响因素也是会不一样的，跟技术架构的演进一样，测试策略也应该是演进式的。

从目标出发，综合所处阶段各个方面的影响因素，制定出适合当时的测试策略。随着时间的推移，对策略进行评估和度量，并进一步改进、提高，以更好的满足需求。这就是目标驱动的演进式测试策略。

（演进式测试策略）

微服务架构下多个服务的整合是最具有挑战的，对此最重要的是契约测试。契约测试有效保证服务间的契约关系不被破坏，确保服务的连通性，有助于实现真正的独立部署和独立交付。

微服务架构引入的不确定性并不是坏事，可以利用这些不确定性，采用生产环境下的QA等技术，增强系统的反脆弱性，从中获益。

测试策略的影响因素不是唯一的，技术架构并不是最关键的因素。微服务架构下的测试策略跟其他架构下的并不会有本质的区别。

业务价值始终是我们的终极目标。在这个终极目标的驱动下，测试策略不是制定完了就可以束之高阁的，需要在整个软件系统构建过程中不断的度量和改进，是演进式的。

文/ThoughtWorks 林冰玉

微服务与分布式系统架构问题如何解决

如果大家了解微服务和分布式服务器架构等技术的话，那么对于如何解决系统运行中出现的BUG造成的破坏和损失这些问题也应该有自己独到的见解吧。今天，电脑培训就一起来了解一下，在服务器运行过程中出现的问题都有哪些解决方法。

随着微服务和分布式云架构的崛起，Web变得日趋复杂，“随机性”的故障因此变得越来越难以预测，而我们对这些系统的依赖却与日俱增。

这些故障给公司造成巨大损失，也给用户带来很大的麻烦，影响他们进行在线购物、交易或打断他们的工作。即使是一些简单的故障也会触及公司的底线，因此，宕机时间就成为很多工程团队的KPI。2017年，有98%的企业表示，一小时的宕机时间将给他们带来超过10万美元的损失。一次服务中断有可能让一个公司损失数百万美元。近，英国航空的CEO透露，2017年5月发生的一次技术故障造成数千名乘客滞留机场，给公司造成8000千万英镑的损失。

企业需要想办法解决这些问题，因为等到下一次事故发生就为时已晚。为此，混沌工程应运而生。

混沌工程旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。

混沌工程将预想的事情与实际发生的事情进行对比，通过“有意识地搞破坏”来提升系统的弹性。

混沌工程简史

混沌工程先出现在互联网巨头公司中，这些公司拥有大规模的分布式系统，因为这些系统太过复杂，他们需要一些新的手段来测试它们。

2010年

NetflixEngTools团队开发出了ChaosMonkey。当时，Netflix从物理基础设施迁移到AWS上，为了保证AWS实例的故障不会给Netflix的用户体验造成影响，他们开发了这个工具，用来测试系统。

2011年

SimianArmy诞生，在ChaosMonkey的基础上增加了故障注入模式，可以测试更多的故障场景。Netflix认为，云的特点是冗余和容错，但没有哪个组件能够保证100%的可用性，所以他们必须设计出一种云架构，在这种架构里，个体组件的故障不会影响到整个系统。

2012年

Netflix在GitHub上开源了ChaosMonkey，并声称他们“已经找到了应对主要非预期故障的解决方案。通过经常性地制造故障，我们的服务因此变得更有弹性。”

2014年

Netflix团队创建了一种新的角色，叫作混沌工程师。BruceWong发明了这个角色，并由DanWoods在Twitter上向广大的工程社区推广。DanWoods解释说，“我从KoltonAndrus那里学到了更多有关混沌工程的知识，他把它叫作故障注入测试”。

2014年10月，当时Gremlin的联合创始人KoltonAndrus还在Netflix，他们在SimianArmy的基础上提出了故障注入测试(FIT)概念，开发者可以更灵活地控制注入故障的“杀伤力范围”。因为SimianArmy有时候会造成非常严重的故障，所以Netflix的开发者对它抱有疑虑，而FIT可以更好地控制故障粒度，于是他们就由此想出了混沌工程这个概念。