我并不期待人生能够始终过得很顺利，但我心愿碰到人生难关的时候，本人能够是它的对手。
独自的数据库
微服务设计的一个要害是数据库设计，根本准则是每个服务都有本人独自的数据库，而且只有微服务自身能够拜访这个数据库。它是基于上面三个起因。
- 优化服务接口：微服务之间的接口越小越好，最好只有服务调用接口（RPC 或音讯），没有其余接口。如果微服务不能独享本人的数据库，那么数据库也变成了接口的一部分，这大大拓展了接口范畴。
- 错误诊断：生产环境中的谬误大部分都是和数据库无关的，要么是数据出了问题，要么是数据库的应用形式出了问题。当你不能齐全管制数据库的拜访时，会有各种各样的谬误产生。它可能是别的程序间接连到你的数据库或者是其余部门间接用客户端拜访数据库的数据，而这些都是在程序中查不到的，减少了谬误排查难度。如果是程序中的问题，只有批改了代码，那么这个谬误就不会再有。而下面提到的谬误，你永远都没法预测它们什么时候还会再次发生。
- 性能调优：性能调优也是一样，你须要对数据库有全权管制能力保障它的性能。如果其余部门肯定要拜访数据库，而且只是查问的话，那么能够另外创立一份只读数据库，让他们在另一个库中查问，这样才不会影响到你的库。
现实的设计是你的数据库只有你的服务能拜访，你也只调用本人数据库中的数据，所有对别的微服务的拜访都通过服务调用来实现。当然，在理论利用中，单纯的服务调用可能不能满足性能或其余要求，不同的微服务都多少须要共享一些数据。
共享数据
微服务之间的数据共享能够有下四种形式。
动态表
有一些动态的数据库表，例如国家，可能会被很多程序用到，而且程序外部须要对国家这个表做连贯（join）生成最终用户展现数据，这样用微服务调用的形式就效率不高，影响性能。一个方法是在每个微服务中配置一个这样的表，它是只读的，这样就能够做数据库连贯了。当然你须要保证数据同步。这个计划在少数状况下都是能够承受的，因为以下两点：
- 动态的数据库表构造根本不变：因为一旦表构造变了，你岂但要更改所有微服务的数据库表，还要批改所有微服务的程序。
- 数据库表中的数据变动不频繁：这样数据同步的工作量不大。另外当你同步数据库时总会有提早，如果数据变动不频繁那么你有很多同步形式可供选择。
只读业务数据拜访
如果你须要读取别的数据库里的动静业务数据，现实的形式是服务调用。如果你只是调用其余微服务做一些计算，个别状况下性能都是能够承受的。如果你须要做数据的连贯，那么你能够用程序代码来做，而不是用 SQL 语句。如果测试之后性能不能满足要求，那你能够思考在本人的数据库里建一套只读数据表。数据同步形式大抵有两种。如果是事件驱动形式，就用发消息的形式进行同步，如果是 RPC 形式，就用数据库自身提供的同步形式或者第三方同步软件。
通常状况下，你可能只须要其余数据库的几张表，每张表只须要几个字段。这时，其余数据库是数据的最终起源，管制所有写操作以及相应的业务验证逻辑，咱们叫它主表。你的只读库能够叫从表。当一条数据写入主表后，会发一条播送音讯，所有领有从表的微服务监听音讯并更新只读表中的数据。但这时你要特地小心，因为它的危险性要比动态表大得多。第一它的表构造变更会更频繁，而且它的变更齐全不受你管制。第二业务数据不像动态表，它是常常更新的，这样对数据同步的要求就比拟高。要依据具体的业务需要来决定多大的提早是能够承受的。
另外它还有两个问题：
- 数据的容量：数据库中的数据量是影响性能的次要因素。因为这个数据是外来的，不利于把握它的流量法则，很难进行容量布局，也不能更好地进行性能调优。
- 接口外泄 ：微服务之间的接口原本只有服务调用接口，这时你能够对外部程序和数据库做任何更改，而不影响其余服务。当初数据库表构造也变成了接口的一部分。接口一旦公布之后，根本是不能更改的，这大大限度了你的灵活性。侥幸的是因为另外建了一套表，有了一个缓冲，当主表批改时，从表兴许不须要同步更新。
除非你能用服务调用（没有本地只读数据库）的形式实现所有性能，不然不论你是用 RPC 形式还是事件驱动形式进行微服务集成，下面提到的问题都是不可避免的。然而你能够通过正当布局数据库更改，来缩小下面问题带来的影响，上面将会具体解说。
读写业务数据拜访
这是最简单的一种状况。个别状况下，你有一个表是主表，而其余表是从表。主表蕴含次要信息，而且这些次要信息被复制到从表，但微服务会有额定字段须要写入从表。这样本地微服务对从表就既有读也有写的操作。而且主表和从表有一个先后秩序的关系。从表的主键来源于主表，因而肯定先有主表，再有从表。
上图是例子。假如咱们有两个与电影无关的微服务，一个是电影论坛，用户能够发表对电影的评论。另一个是电影商店。“movie”是共享表，右边的一个是电影论坛库，它的“movie”表是主表。左边的是电影商店库，它的“movie”表是从表。它们共享“id”字段（主键）。
主表是数据的次要起源，但从表里的“quantity”和“price”字段主表外面没有。主表插入数据后，发消息，从表接到音讯，插入一条数据到本地“movie”表。并且从表还会批改表里的“quantity”和“price”字段。在这种状况下，要给每一个字段调配一个惟一源头（微服务），只有源头才有权力被动更改字段，其余微服务只能被动更改（接管源头收回的更改音讯之后再改）。
在本例子中，“quantity”和“price”字段的源头是左边的表，其余的字段的源头都是右边的表。本例子中“quantity”和“price”只在从表中存在，因而数据写入是单向的，方向是主表到从表。如果主表也须要这些字段，那么它们还要被回写，那数据写入就变成双向的。
间接拜访其它数据库
这种形式是要相对禁止的。生产环境中的许多程序谬误和性能问题都是由这种形式产生的。下面的三种形式因为是另外新建了本地只读数据库表，产生了数据库的物理隔离，这样一个数据库的性能问题不会影响到另一个。另外，当主库中的表构造更改时，你能够临时放弃从库中的表不变，这样程序还能够运行。如果间接拜访他人的库，主库一批改，别的微服务程序马上就会报错。请参阅 ApplicationDatabase。
向后兼容的数据库更新
从下面的阐述能够看出，数据库表构造的批改是一个影响范畴很广的事件。在微服务架构中，共享的表在别的服务中也会有一个只读的拷贝。当初当你要更改表构造时，还须要思考到对别的微服务的影响。当在单体（Monolithic）架构中，为了保障程序部署可能回滚，数据库的更新是向后兼容的。
须要兼容性的另一个起因是反对蓝绿公布（Blue-Green Deployment）。在这种部署形式中，你同时领有新旧版本的代码，由负载平衡来决定每一个申请指向那个版本。它们能够共享一个数据库（这就要求数据库是向后兼容的），也能够应用不同的数据。数据库的更新简略来讲有以下几种类型：
- 减少表或字段：如果字段可取空值，这个操作是向后兼容的。如果是非空值就要插入一个缺省值。
- 删除表或字段：可先临时保留被删除表或字段，通过几个版本之后再删除。
- 批改字段名：新减少一个字段，把数据从旧字段拷贝到新字段，用数据库触发器（或程序）同步旧字段和新字段（供过渡时期应用）。而后再在几个版本之后把原来的字段删除（请参阅 Update your Database Schema Without Downtime）。
- 批改表名：如果数据库反对可更新视图，最简略的方法是先批改表的名字，而后创立一个可更新视图指向原来的表（请参阅 Evolutionary Database Design）。如果数据库不反对可更新视图，应用的办法与批改字段名类似，须要创立新的表并做数据同步。
- 批改字段类型：与批改字段名简直雷同，只是在拷贝数据时，须要做数据类型转换。
向后兼容的数据库更新的益处是，当程序部署呈现问题时，如需进行回滚。只有回滚程序就行了，而不用回滚数据库。回滚时个别只回滚一个版本。但凡须要删除的表或字段在本次部署时都不做批改，等到一个或几个版本之后，确认没有问题了再删除。它的另一个益处就是不会对其余微服务中的共享表产生立即的间接影响。当本微服务降级后，其余微服务能够评估这些数据库更新带来的影响再决定是否须要做相应的程序或数据库批改。
跨服务事物
微服务的一个难点是如何实现跨服务的事物反对。两阶段提交（Two-Phase Commit）已被证实性能上不能满足需要，当初基本上没有人用。被统一认可的办法叫 Saga。
它的原理是为事物中的每个操作写一个弥补操作（Compensating Transaction），而后在回滚阶段挨个执行每一个弥补操作。示例如下图，在一个事物中共有 3 个操作 T1，T2，T3。每一个操作要定义一个弥补操作，C1，C2，C3。事物执行时是依照正向程序先执行 T1，当回滚时是依照反向程序先执行 C3。
事物中的每一个操作（正向操作和弥补操作）都被包装成一个命令（Command），Saga 执行协调器（Saga Execution Coordinator (SEC)）负责执行所有命令。在执行之前，所有的命令都会按程序被存入日志中，而后 Saga 执行协调器从日志中取出命令，顺次执行。当某个执行呈现谬误时，这个谬误也被写入日志，并且所有正在执行的命令被进行，开始回滚操作。
Saga 放松了对一致性（Consistency）的要求，它能保障的是最终一致性（Eventual Consistency），因而在事物执行过程中数据是不统一的，并且这种不统一会被别的过程看到。在生活中，大多数状况下，咱们对一致性的要求并没有那么高，短暂的不一致性是能够接管的。例如银行的转账操作，它们在执行过程中都不是在一个数据库事物里执行的，而是用记账的形式分成两个动作来执行，保障的也是最终一致性。
Saga 的原理看起来很简略，但要想正确的施行还是有肯定难度的。它的外围问题在于对谬误的解决，要把它齐全讲明确须要另写一遍文章，我当初只讲一下要点。网络环境是不牢靠的，正在执行的命令可能很长时间都没有返回后果，这时，第一，你要设定一个超时。第二，因为你不晓得没有返回值的起因是，曾经实现了命令但网络出了问题，还是没实现就就义了，因而不晓得是否要执行弥补操作。这时正确的做法是重试原命令，直到失去实现确认，而后再执行弥补操作。但这对命令有一个要求，那就是这个操作必须是幂等的（Idempotent），也就是说它能够执行屡次，但最终后果还是一样的。
另外，有些操作的弥补操作比拟容易生成，例如付款操作，你只有把钱款退回就能够了。但有些操作，像发邮件，实现之后就没有方法回到之前的状态了，这时就只能再发一个邮件更正以前的信息。因而弥补操作不肯定非要返回到原来的状态，而是对消掉原来操作产生的成果。
微服务的拆分
咱们原来的程序大多数都是单体程序，但当初要把它拆分成微服务，应该怎么做能力升高对现有利用的影响呢？
咱们用下面的图来做例子。它共有两个程序，一个是“Styling app”，另一个是“Warehouse app”，它们共享图中上面的数据库，库里有三张表，“core client”，“core sku”，“core item”。
假如咱们要拆分进去一个微服务叫“client-service”，它须要拜访“core client”表。第一步，咱们先把程序从原来的代码里拆分进去，变成一个服务. 数据库不动，这个服务依然指向原来的数据库。其余程序不再间接拜访这个服务治理的表，而是通过服务调用或另建共享表来获取数据。
第二步，再把服务的数据库表拆分进去，这时微服务就领有它本人的数据库了，而不再须要原来的共享数据库了。这时就成了一个真正意义上的的微服务。
下面只讲了拆分一个微服务，如果有多个须要拆分，则需一个一个依照下面讲的办法顺次进行。
另外，Martin Fowler 在他的文章 ”Break Monolith into Microservices” 里有一个很好的倡议。那就是，当你把服务从单体程序里拆分时，不要只想着把代码拆分进去。因为当初的需要可能曾经跟原来有所不同，原先的设计可能也不太实用了。而且，技术也已更新，代码也要作相应的革新。更好的方法是重写原来的性能（而不是重写原来的代码），把重点放在拆分业务性能上，而不是拆分代码上，用新的设计和技术来实现这个业务性能。
论断
数据库设计是微服务设计的一个关键点，根本准则是每个微服务都有本人独自的数据库，而且只有微服务自身能够拜访这个数据库。微服务之间的数据共享能够通过服务调用，或者主、从表的形式实现。在共享数据时，要找到适合的同步形式。在微服务架构中，数据库的批改影响宽泛，须要保障这种批改是向后兼容的。实现跨服务事物的规范办法是 Saga。当把单体程序拆分成微服务时，能够分步进行，以缩小对现有程序的影响。