来自Stitch Fix团队的工程副总裁Randy Shoup在QCon纽约2017会议上讨论了如何在基于微服务的应用中管理数据和隔离持久化。他还介绍了将事件(Event)作为微服务的第一类构造。他介绍自己的团队将机器学习技术应用到了业务的各个组成部分，比如购买、库存管理以及风格推荐等。
个性化推荐会基于库存运行机器学习，从而创建出推荐的算法。这些推荐算法随后会被全国范围内的设计师所监管，从而形成个性化风格的推荐。
微服务架构是渐进演化的。像eBay、Twitter和Amazon这样的组织都经历了一些架构的迭代，从单体应用转换成了微服务。
微服务除了具有单一的目的、定义良好的接口、模块化和独立性之外，还需要负责隔离持久化。Shoup讨论了一些持久化的方式，比如操作自己的数据存储或使用持久化服务。在第一种方式中，会将数据存储在自己的数据库实例中，这个实例是由服务团队拥有并进行运维的。而如果采用持久化服务的话，我们会将数据存储在数据库的一个单独的模式中，由其他团队或第三方供应商以服务的方式进行运维。数据应该是与服务的其他消费者相隔离的。
事件是微服务架构中的第一类构造。它们代表了现实世界是如何运作的并且保证应用符合一定的领域要求，比如在金融方面。事件是服务接口的重要组成部分，它应该包含服务产生的所有事件以及服务消费的所有事件。
从单体共享数据库抽取微服务一般涉及到如下几个步骤：
创建服务：服务边界应该包含服务本身以及它所面对的数据库;应用要使用服务：通过使用新创建的服务，让应用与共享数据库解耦;将数据转移至私有数据库：然后将数据从共享数据库转移至新的私有数据库。这不会对客户端应用造成任何影响，因为它们已经不直接依赖于数据库;重复操作：为应用中需要抽取成独立微服务的其他业务功能采用相同的过程。
Shoup还讨论到微服务用例涉及到共享数据(Shared Data)、连接(join)以及事务。
共享数据：创建的服务是单一系统记录(System of Record，SoR)的并且拥有自己的所有数据。数据的其他副本是只读的，只是非权威(non-authoritative)的缓存。为了访问共享数据，我们有三个可选方案：同步查找(一个服务调用另外的服务来获取数据)、具有缓存的异步事件或共享元数据库;
连接：将数据切分为单独的服务会让连接变得很困难。在微服务领域中，我们可以在客户端应用中进行数据连接，或者是通过监听两个服务的事件，创建“物化视图(Materialized Views)”，并在本地存储中维护非规格化(denormalized)的两个数据集的连接结果。
事务：在单体应用中，事务管理非常容易，但是在微服务架构中却非常困难，因为数据被拆分到了多个不同的服务中了。我们可以将事务实现为一种工作流，它会按照倒序使用补偿操作从而形成一种回滚机制。很多现实系统已经采用了这种方式，比如支付处理和费用审批的系统。这些流程也是采用功能即服务(Serverless架构)的理想候选方案。
本文作者：Srini Penchikala
来源：51CTO
