微服务-在一个有多个业务的组织中

Question

上下文

假设我们有一个有多种业务的组织。在这个例子中，Business A向大学生出售千兆位的互联网服务。商务B公司向老年人出售一种兆位互联网服务。这些企业销售的相关产品略有不同，每一种都针对不同的人口群体。

乍一看，这似乎只需要一个应用程序处理所有请求。然而，企业之间的分歧是很自然的，因为它们各自针对的是一个特定的人口群体--从本质上说，每个企业都有自己的业务需求。例如，Business可能公开一个移动应用程序，以便客户管理他们的帐户。业务B可能会公开一个电话号码，客户必须打电话来管理他们的帐户。清单不胜枚举。

在这种情况下，使用微服务的最佳方法是什么？

问题是，在不同的业务中都有共同的和不常见的功能。

我们可以保持一些干燥，并有一套基本的微服务(计费-api，订单-api等)。可以被不同的企业所消费。这是可行的，但这会导致微服务具有更多的“通用”抽象，从而导致更多的复杂性。具体的例子是，假设计费-api服务有一个由业务A和B共享的/charge端点。业务B的要求是总是从订单中打折5美元：

//billing-api

if (businessB) { 
  orderCost -= 5; 
}

在这种枯燥的方法中，我们将为每个业务提供一个API网关(BFF模式)，它将聚合不同的微服务以满足它们的业务需求。所有“特定于业务”的逻辑都将从基本的微服务转移到相应的业务API网关。在这个折扣示例中，我们可以将此控件倒转到使用者，而不是在计费-api端点中进行if (businessB)检查：

//billing-api

const { orderDiscountAmount } = req.body; //body parameters

if (orderDiscountAmount > 0) { 
  orderCost -= orderDiscountAmount; 
}

然后，在调用计费- API端点时，Business的api网关中的端点将传递为5的orderDiscountAmount：

//Business B API Gateway

billingApi({ orderDiscountAmount: 5 });

这似乎很好，但我们所做的只是在计费-api端点中使用了Business的逻辑，并创建了一个通用(但却是强制的)抽象。这是“合理的”说，也许商业A可能会使用这一天--但这可能永远不会发生。总的来说，对于开发人员和端点的使用者来说，这是一个不自然的练习。各方面的复杂性和认知负荷都在增加。

为了最大限度的灵活性和简单性，我们可以废弃干，避免在企业之间共享微服务。然而，如果增加更多的业务(10-20)，那么可能会有大量的重复功能。

在这种情况下，团队应该如何构建？

如果我们对上面的枯燥方法没有意见，那么团队应该如何构建呢？我们可以有垂直分割的特性团队，但这是否意味着如果我们有10家企业，一个团队就需要拥有所有业务的特性(即结帐)？这种方法的缺点是，特性团队不会是任何业务的整体专家--在给定的业务中，这些团队只会是某一特性的专家。没有完整的商业背景，就很难做出正确的决定。

我们可以为每个业务建立一个流对齐团队，专门用于UI和API网关。然后，我们将让平台团队创建微服务，供与流对齐的团队使用。这样做的缺点是在流对齐的团队和平台团队之间有一个切换步骤，即依赖关系。

我不知道我是不是从错误的镜头看所有这些-任何反馈都会感谢！

Answer 1

很抱歉，但是这对于Stackoverflow来说不是一个好问题，因为任何答案都是基于意见的，而且许多方法都可能有效，并且取决于特定用例中的更多细节。所以，如果问题在某个时候结束了，不要失望。

话虽如此，我并不羞于提出我的意见，或至少对你所描述的情况提出一些想法。

1. 我相信您关于如何建立团队和如何设置架构的问题是紧密联系在一起的，因为架构无疑会有效地遵循组织结构。因此，我将首先对组织设置进行进一步的思考。

，

1. ，一种对每个企业所需的总人力的估计，应该会让您了解您需要多少个团队。尽量保持团队规模小(比如2-8人)将有助于减少沟通开销。因此，如果您认为这是整个业务的大小，那么就没有必要进一步拆分responsibility.
2. Responsibility是最重要的关键字。您必须避免使用公共服务/库但有多个所有者或没有所有者的任何情况。总是应该有一个组织所有者。因此，当组织认识到不同领域的功能重叠时，通常的做法是建立一个将负责并向其他人提供此功能的团队。这可以是共享库的形式，也可以是实际部署的服务。在这两种情况下，重要的是通过正确地对他们的工作进行版本化，并将其留给要使用的使用版本、何时升级、添加新特性请求等来实现通信的形式化。这种方法将使使用此通用functionality.
3. In的团队解耦--您的问题描述的核心是业务逻辑和复杂性/重叠。因此，我认为最重要的角色是产品管理。它们必须是非常好的(至少是有点技术性的)，并将这种混乱分类为只针对单个业务的可重用的片段和东西。如果您有一个完整的产品经理团队，他们需要很好地沟通，并共同构建这幅图。这里最重要的是就未来的远景进行良好的沟通，而不仅仅是直接的需求(提供一个很好的领域视图)。只有这样，架构和团队才能以最好的方式建立起来。
4. ，无论最初的设置多么小心，都会发生更改。无论你最初认为是什么最好的解决方案，都会在将来的某个时刻发生变化。为了做好这方面的准备，我总是建议采用最简单的方法--即使这意味着一些代码重复或其他缺陷。作为软件架构师，我们倾向于喜欢完美的美，但这在现实世界中很少是最有效的方法。
5. 通过添加一些可配置性来创建一个简单的共享服务/库，以适应多个用例。在一定程度上，这是一种有用的方法，但您必须对该库/服务的使用者敏感，并且在任何时候都应该易于重用。功能何时变得太大/太复杂，并且必须分割成多个部分才能维护，这并不是白纸黑字，但是用维护者的眼睛和消费者的眼睛来看待它将使判断变得更加容易。在可配置服务库的情况下，您还可以使用不同配置的单独部署，因此使用共同开发的组件，但为每个用例部署不同的端点。如果您使用的技术只产生较小的部署开销(例如，只有几个mbs的golang容器)，那么大量部署的服务不是缺点，而是一种优势，因为它们可以独立地升级/版本化，甚至在parallel.
6. Infrastructure中运行多个版本也很容易，服务部署可能遵循服务的体系结构，也可能不遵循服务的体系结构。作为一般规则，我建议寻找最简单的方法，这通常意味着提供在服务之间共享的公共基础设施，而部署配置正是服务之间的区别所在。例如，所有服务共享一个公共集群/流/网关/数据库/等等。对于单个服务来说，异常可能是非常特殊的需求，例如用于机器学习的硬件加密密钥存储或GPU服务器等。这将是任何合理大小的系统的方法。(当然，如果您要扩展到非常大的规模，为特定的services.)
7. Persistency设计提供完整的堆栈/集群也是非常可行的方法。在业务逻辑的发展、重组等相对容易的地方，演化历史数据是相当困难的。通常，您可以选择以两种方式之一进行设计：
   1. 智能算法、哑数据、
   2. 智能数据、哑数据。

(明智地指更详细的/反映更多的业务需求)第二种方法最初通常比较困难，但在我的经验中，当达到一定的复杂性阈值时，效果会更好。

当我读到你的问题时，这些只是我脑海中浮现的几件事。我很抱歉，他们不能回答你关于如何分割计费API的详细问题，但是也许您手头还有一些额外的考虑。