数据隔离：

实际上，服务化的其中一个基本原则就是数据隔离，不同服务应该有自己的专属数据库，而不应该共用相同的数据库，数据访问可以通过服务接口或者消息队列的方式。

很多公司微服务化后，只做了代码工程的拆分，不同服务对应的数据仍然存放在同一个数据库中。这样做至少存在四个问题：

1，数据安全问题。别人的服务不但可以访问你的数据，而且还能修改和删除你的数据。

2，导致数据库连接耗尽。一旦某个服务的开发者写了一个慢SQL，并且这个服务也没有合理限制连接数。可能会消耗掉所有的数据库连接，进而造成访问相同数据库的其他服务拿不到数据库连接，无法访问数据库。

3，表关联查询。无法避免其他服务的开发者，为了快速上线某些需求。直接查询其他服务的表，或者跨服务做表关联查询。这样会造成服务间的耦合越来越严重。

4，表结构变化的影响。如果某个服务直接依赖于其他服务的数据，一旦表结构发生任何变化，比如修改表名或者字段。很可能会产生灾难性后果。

部署隔离：

我们经常会遇到秒杀业务和日常业务依赖同一个服务，以及C端服务和内部运营系统依赖同一个服务的情况，比如说都依赖支付服务。而秒杀系统的瞬间访问量很高，可能会对服务带来巨大的压力，甚至压垮服务。内部运营系统也经常有批量数据导出的操作，同样会给服务带来一定的压力。这些都是不稳定因素。所以我们可以将这些共同依赖的服务分组部署，不同的分组服务于不同的业务，避免相互干扰。

业务隔离：

以秒杀为例。从业务上把秒杀和日常的售卖区分开来，把秒杀做为营销活动，要参与秒杀的商品需要提前报名参加活动，这样我们就能提前知道哪些商家哪些商品要参与秒杀，可以根据提报的商品提前生成商品详情静态页面并上传到CDN预热，提报的商品库存也需要提前预热，可以将商品库存在活动开始前预热到Redis，避免秒杀开始后大量访问穿透到数据库。