玄姐新书《架构真意》来了!!文末送书!

现如今我们进入了一个软件业快速变化的年代，越来越多的团队为了适应互联网高并发、高可用的架构特点，都选择了微服务架构。然而，并非只要转型成微服务就能解决问题。准确地理解微服务非常重要，它可以帮助我们充分利用微服务的优势为我所用。相反，如果理解不到位，而是简单粗暴地按照功能模块拆分微服务，则不能有效规避微服务的劣势，给团队带来灾难性的后果。这里准确理解微服务的核心就是“小而专”的微服务。

微服务的最大特点就是“小而专”。这里的“小”比较容易理解，就是将原有大的单体应用拆分成一系列小的微服务。然而，以往大家的理解都片面强调了“小”而忽略了“专”。这里的“专”就是专注、就是单一职责，也就是高内聚。高内聚的设计对于微服务来说非常重要，因为微服务的优势就在于，每次在变更的时候，如果只更新一个微服务，那么把该微服务更新了，只升级与发布该微服务，就可以实现快速交付的目的。然而，如果这个假设不成立，在变更的时候需要更新多个微服务，那么每个微服务都要更新、都要测试，并且还要同时发布。这时，微服务架构的优势就荡然无存。

那么，怎样才能保证每次变更都只更新一个微服务呢？关键在于我们对单一职责的理解。所谓“单一职责原则”就是要求每个元素只完成自己职责范围内的事，而将其它的事交给别人去做，我只是调用它的接口。这里理解的关键就在于这个“职责”，什么是我职责范围内的，什么是我职责范围外的。对于职责正确的理解就是“一个职责就是软件变化的一个原因”，而对这句话的理解非常重要。

高质量软件设计的目的就在于，在每次需求变更的时候能有效地降低代码的维护成本，以低成本的状态维护系统。如果每次变更的时候都需要变更多个模块的代码，维护成本必然就非常高。因此，就需要我们在平时一边维护代码，一边整理代码，就软件变化同一个原因的代码放到一起，而将软件变化不同原因的代码分开放，放到不同模块、不同类中。这样，当每次需要变更时，因为这个原因而需要修改的代码就只需要修改这个模块、这个类，维护成本就降低了。

落实到微服务设计，就是将软件变化同一个原因的代码放在一个微服务中，而将软件变化不同原因的代码放到不同的微服务中。那么，因这个原因而变更的代码都在这个微服务上，微服务的优势才能真正发挥出来。因此，微服务的设计，不是简单粗暴地将应用按照功能模块拆分成几个微服务那么简单的事情，而是需要提升原有的设计能力。将应用按照功能模块拆分，如果每次变更都会涉及到多个微服务，不仅不能提升研发效率，还使得效率更低。因此，需要在模块拆分的同时，提高原有设计的聚合度。

此外，在拆分微服务的同时，也在拆分数据库。如图所示，最理想的状态是每个微服务都有自己的数据库，并且只访问自己的数据库。但这样的设计使得微服务转型的初期会带来大量的数据库拆分与迁移，进而带来诸如跨库的事务处理、跨库的关联查询等设计难题。因而，从更加现实的角度出发，在微服务转型的初期往往采用数据共享的模式，即多个微服务共同使用一个数据库。这样的设计是一种现实的折中，虽然更加落地，但会带来“数据共享”反模式的设计问题。

微服务技术架构与数据库

所谓的“数据共享”反模式，就是多个微服务共用一个数据库，使得这个数据库一旦变更，多个微服务同时都需要变更的设计问题。譬如，多个微服务都要访问商品信息表，那么一旦商品信息表发生变更，则多个微服务都会变更，从而使得变更成本巨大。这里“数据共享”反模式问题的本质不在于“数据共享”模式本身不好，而在于我们的设计不到位。

这里，怎么叫设计到位呢？在微服务转型的过程中，在拆分微服务的同时，需要制订一个规范，即数据库中的每个表只能有一个微服务去访问，其它微服务要访问这个表只能通过调用那个微服务的接口间接访问。如下图所示，我们以往的设计是这样的，每个模块都通过JDBC直接访问数据库中的各个表。如果按照这样的设计直接简单粗暴的拆分成微服务，那么一旦商品信息表发生变更，多个微服务都必须得变更，然后还要同时升级，微服务的优势将荡然无存。

烟囱式的微服务设计

小而专的微服务设计，需要在微服务转型时，设计一定要到位。在按照模块拆分微服务的同时，对数据库中的所有的表进行规划，哪个表属于哪个微服务。一旦规划好，这个表属于这个微服务，那么只能由这个微服务访问这个表，其它微服务都不能访问。如下图所示，商品信息表通过规划属于“商品维护”这个微服务，那么对商品信息表的读写都只能由“商品维护”微服务来完成。如果其它微服务也有获取商品信息，就只能通过调用“商品维护”微服务的接口。这样，当商品信息发生变更时，就只跟“商品维护”微服务有关，它独立修改然后独立升级，这个变更就实现了，与其它微服务无关，维护成本就降低了。

小而专的微服务设计

那么，如何保证这个规范在微服务转型过程中得到遵守呢？最有效地措施就是从逻辑上划分用户。这时，虽然在物理上，各微服务都是访问这一个数据库，然而在逻辑上将这个数据库划分为多个用户，每个微服务只有通过自己的权限访问自己的表。当需要访问其它表时，自然就会申请去调用相应微服务的接口，微服务的设计质量就得到保证了。

• 落地、实践，为架构师提供切实可行、操作性强的架构设计方法；

• 难题、方案，为架构师解决项目实践中的设计难题提供思路与方案；

• 前瞻、全局，为架构师展现未来技术发展趋势。

重点来了，如何获取这本书呢？你需要点赞 + 在看这篇文章，并在这篇文章下面留言，我会选取点赞量最高的 4 位小伙伴送书这本书籍。截止时间在 9 月 6 号早上 8 点哦！

另外，感谢华章的赞助，这本书大家也可以在当当买到 👇