人们之所以会采用微服务架构，一个非常重要的原因就是这种架构允许不同的团队分工协作，各自推进，互不影响。那么怎样做才能实现微服务架构呢？最近Red Hat的首席中间件架构师、开源爱好者和Apache代码提交者Christian Posta在博客上发表了一篇文章分享了自己的看法，他认为单纯地使用Spring Boot、Dropwizard或者Docker并不意味着你已经走在了微服务的路上，要真正地实现微服务，必须要深入理解领域和数据。
对于数据，有人认为每一个微服务都应该拥有并控制自己的数据库，任意两个微服务都不应该共享同一个数据库，因为如果共享数据库就会有读、写竞争，数据模型冲突，协调难度大等问题；而统一的数据库则安全性更高，更便利，更容易理解和管理。那么在构建微服务的时候应该如何权衡、协调这些问题呢？Christian Posta认为对于一个正在构建微服务架构的企业，首先应该搞清楚下面四个问题：
领域是什么？实际情况是什么？ 事务的边界在哪里？ 微服务应该采用什么方式实现跨边界通信？ 如果把数据库拿出来会怎样？
Christian Posta首先解释了什么是领域，他认为在构建微服务之前必须充分而深入的理解数据的含义、了解数据是如何产生与消费的。例如，如何给“书”下定义，如何用数据模型表示它：
书是带页码的东西？那报纸是书么（它也页码）？书有硬的封皮？书不是每天都出版？出版社可能会用一条记录表示某个作者的某本书，但是书店里面可能会有多本这样的书，如何表示这种关系呢？假如一本书太长必须分卷，应该如何处理？每一卷都是一本书，还是合到一起才算？
对于这种问题现实情况是没有万能的答案，关键是看“谁问的问题，上下文是什么”。不同的上下文对同一问题的理解可能不同，作为人类我们能很容易地理解“书”是什么，但是计算机不能，在构建软件和数据建模的时候必须使计算机对上下文清晰明了。为此领域驱动设计（DDD）能够帮助我们处理其中的复杂性，通过领域模型建立数据模型，然后在实体、值对象之间画出边界，这些边界或者边界里的组件可能就是最终的微服务。
在数据模型和边界确定之后就需要一些方式来协调不同模型使之保持数据的一致性，这就需要找出事务的边界在哪里。Christian Posta认为事务边界是业务不可变性的最小原子单元。无论是通过数据库的ACID特性还是通过两阶段提交来实现原子性，都无所谓，关键是要让事务的边界尽可能地小。例如，针对下面几个用例：
“允许客户搜索航班”
“允许客户选择某个特定航班的座位”
“允许客户预定某个航班”
可能会有三个有边界的上下文：搜索、预定和售票。搜索负责显示特定路线的航班以及给定时间范围内的旅游活动日程。预定通过客户的姓名、地址、经常乘坐的航班、座位喜好以及支付信息等安排预定流程。售票负责实际的订票和出票。这一阶段需要识别出每一个上下文中的事务边界从而实施约束/不可变性，保证不同上下文内的事务互不影响；但是此时并不需要100%的、严格的数据一致性，因此不需要考虑跨边界上下文的原子事务。例如，对于上面的场景：
预定流程可能会调用SeatAvailability服务让它在飞机上预留一个座位。这个座位预留的操作可能会实现为一个单独的事务（比如保留座位23A）并返回一个预留ID号。预定流程会关联该预留ID号并提交预定。无论是预留座位还是接受预定，它们各自都是一个单独的事务，可以独立处理，不需要借助于两阶段提交或者两阶段锁。
但是数据并不是孤立的，在某些情况下独立的事务需要组合到一起，那么微服务应该采用何种方式跨边界通信呢？Christian Posta认为微服务的价值在于自治，在于每一个系统都能够独立的变化，为了在实现自治的同时又保证业务需求，“事件机制”是非常好的选择。事件是不可变的数据结构，它会及时捕获与某个动作相关的信息，并被广播到其他节点，其他节点会监听它们感兴趣的事件，并根据事件的数据做出决策（存储数据、更新数据等）。例如，对于上面预定机票的场景：
当客户发起预定的时候，预定上下文会发布一个类似于“NewBookingCreated”的事件，售票上下文会消费该事件并与后端的票务系统交互。
使用事件的优点是：它能够避免边界之间昂贵的、不可能的事务模型；系统的各个部分能够独立变化，互不影响；系统的每个部分可以自己决定数据的更新周期，数据的存储方式，以及数据模式等；系统的可伸缩性、容错性和扩展性更好。当然，这种方式也有一些缺点：用户必须花费更多的精力研究CAP理论，了解存储或者队列的实现技术；调试的复杂度更高，实施的难度更高等。
最后，对于“微服务的数据应该存储到一个数据库中还是存储到不同的数据库中”，Christian Posta给出的答案是“没有具体的规则，这需要根据具体的场景进行权衡，标准是不要失去自治所带来的优点”。此外，Christian Posta还给出了一种通过Apache Samza构建事件流处理系统的思路，他认为这样做可以带来更多的好处：
可以将数据库看作是“当前状态”的记录，而不是真正的记录 可以引入新的应用程序，重新读取过去的事件并依据“已经发生的事情”检查它们的行为 可以自由地审计日志 可以引入新版本的应用，并通过回放事件对其进行非常完善的测试 可以非常容易地修改数据库的版本和模式，执行升级，只需要将事件在新数据库中重放即可 可以非常容易地迁移到全新的、不同类型的数据库
本文转自d1net（转载）