微服务的设计模式（二）

在优锐课的学习分享中，讨论了关于微服务的许多设计模式的详细描述。
码了很多专业的相关知识， 分享给大家参考学习。

看到这里迷路的朋友们可以先看本文的上部分内容，这样思路更清晰！
微服务的设计模式（一）

客户端UI组合模式

通过分解业务功能/子域来开发服务时，负责用户体验的服务必须从多个微服务中提取数据。 在整体世界中，从UI到后端服务只有一次调用，以检索所有数据并刷新/提交UI页面。 但是，现在不一样了。 对于微服务，必须将UI设计为具有屏幕/页面的多个部分/区域的框架。 每个部分都将调用单个后端微服务以提取数据。 诸如AngularJS和ReactJS之类的框架可以轻松地做到这一点。 这些屏幕称为单页应用程序（SPA）。 每个团队都开发一个客户端UI组件，例如AngularJS指令，该组件实现其服务的页面/屏幕区域。 UI团队负责通过组合多个特定于服务的UI组件来实现构建页面/屏幕的页面框架。

数据库模式

在定义微服务的数据库架构时，我们需要考虑以下几点。
服务必须松散耦合。 它们可以独立开发，部署和扩展。
商业交易可能会强制涉及多个服务的不变式。
一些业务交易需要查询多个服务拥有的数据。
有时必须复制和共享数据库才能进行扩展。
不同的服务具有不同的数据存储要求。

每个服务的数据库

为了解决上述问题，必须为每个微服务设计一个数据库。 它必须仅对该服务专用。 只能由微服务API访问它。 其他服务无法直接访问它。 例如，对于关系数据库，我们可以使用