让我们讨论一下微服务环境的架构。我们正在公司内部进行讨论，我想要一些反馈意见。我正在认真思考的是编排层（代码重复，更多动态部分更改api）。
webapp - ＆gt;编排 - ＆gt;服务 - ＆gt;持久性
api - ＆gt; api gw - ＆gt;编排 - ＆gt;服务 - ＆gt;持久性
在这种情况下，不允许服务相互通信。业务流程层中的聚合服务
webapp - ＆gt;服务 - ＆gt;持久性
api - ＆gt; api gw - ＆gt;服务 - ＆gt;持久性
这里允许服务相互通信，这里存在聚合服务。
答案 0 :(得分：2)
webapp - ＆gt;编排 - ＆gt; 服务 - ＆gt;坚持
api - ＆gt; api gw - ＆gt;编排 - ＆gt; 服务 - ＆gt;坚持（强调我的）
我们可以备份一下吗？我想问一下这里使用的术语。
对我来说，上面的堆栈在SOA的上下文中没有多大意义。
您将服务夹在称为业务流程和持久性之间。但是，在SOA设计中，所有上述元素都是创建单个服务所必需的。
但是你的例子中 持久性是什么？无论是什么，它似乎都在服务之外。那么服务如何保持数据？ Web应用程序/ API似乎也在服务之外。那么服务如何在屏幕上显示它的数据呢？
如果你看一下SOA的原则，特别是第二个原则：
服务是autonomous
如果服务应该是自治的，那么服务需要负责persisting it's own data。该服务还需要承担责任，通过UI显示其内部状态。
我正在认真思考的是业务流程层
应该遵循这一点，服务也应该对内部国家如何与外部世界进行沟通，包括自身与其他服务之间的关系负责。
如果服务需要使用来自其他服务的数据，则消费者服务部门有责任获取该数据。如果服务的状态发生变化，则该服务有责任让外界了解状态变化。
Orchestration是一个concern，就像持久性，检测等一样，因此在SOA的上下文中最好以分布式，自治的方式实现，而不是作为中心化的方式实现。
所以，在回答你的问题时：
结算属于哪里？
Billing属于它自己的垂直服务堆栈，包括UI视图，持久性，编排，通信，部署和管理。
您更喜欢哪种解决方案？优点/缺点。
如上所述，我认为不应该在提出问题的层面做出选择。我认为无论哪种服务需要编排都应该对它负责。
其他建议？
如果您还没有看过，请查看this。