认识达内从这里开始

随着互联网的不断发展，个性化推荐和猜你喜欢这种基于大数据算法下的信息推送模式开始被大量的平台使用。其根本原因还是因为用户的碎片化时间再不断的减少，只能是在短时间之内让用户看到喜欢的内容而实现用户留存。下面，我们就一起来离开一下关于个性化推荐都是如何来运行的吧。

个性化推荐会基于库存运行机器学习，从而创建出推荐的算法。这些推荐算法随后会被全国范围内的设计师所监管，从而形成个性化风格的推荐。

微服务架构是渐进演化的。像eBay、Twitter和Amazon这样的组织都经历了一些架构的迭代，从单体应用转换成了微服务。

微服务除了具有单一的目的、定义良好的接口、模块化和独立性之外，还需要负责隔离持久化。Shoup讨论了一些持久化的方式，比如操作自己的数据存储或使用持久化服务。在第一种方式中，会将数据存储在自己的数据库实例中，这个实例是由服务团队拥有并进行运维的。而如果采用持久化服务的话，我们会将数据存储在数据库的一个单独的模式中，由其他团队或第三方供应商以服务的方式进行运维。数据应该是与服务的其他消费者相隔离的。

事件是微服务架构中的第一类构造。它们代表了现实世界是如何运作的并且保证应用符合一定的领域要求，比如在金融方面。事件是服务接口的重要组成部分，它应该包含服务产生的所有事件以及服务消费的所有事件。

从单体共享数据库抽取微服务一般涉及到如下几个步骤：

创建服务：服务边界应该包含服务本身以及它所面对的数据库;

应用要使用服务：通过使用新创建的服务，让应用与共享数据库解耦;

将数据转移至私有数据库：然后将数据从共享数据库转移至新的私有数据库。这不会对客户端应用造成任何影响，因为它们已经不直接依赖于数据库;

重复操作：为应用中需要抽取成独立微服务的其他业务功能采用相同的过程。

Shoup还讨论到微服务用例涉及到共享数据(SharedData)、连接(join)以及事务。

共享数据：创建的服务是单一系统记录(SystemofRecord，SoR)的并且拥有自己的所有数据。数据的其他副本是只读的，只是非权威(non-authoritative)的缓存。为了访问共享数据，我们有三个可选方案：同步查找(一个服务调用另外的服务来获取数据)、具有缓存的异步事件或共享元数据库;

连接：将数据切分为单独的服务会让连接变得很困难。在微服务领域中，我们可以在客户端应用中进行数据连接，或者是通过监听两个服务的事件，创建“物化视图(MaterializedViews)”，并在本地存储中维护非规格化(denormalized)的两个数据集的连接结果。

事务：在单体应用中，事务管理非常容易，但是在微服务架构中却非常困难，因为数据被拆分到了多个不同的服务中了。我们可以将事务实现为一种工作流，它会按照倒序使用补偿操作从而形成一种回滚机制。很多现实系统已经采用了这种方式，比如支付处理和费用审批的系统。这些流程也是采用功能即服务(Serverless架构)的理想候选方案。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益！