微服务架构，多“微”才合适？

随着数据量、并发量、业务复杂度的增长，互联网架构会出现以下问题：

创新互联主要从事成都做网站、成都网站制作、网页设计、企业做网站、公司建网站等业务。立足成都服务工布江达,10多年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:028-86922220

“服务化”是一个很好的解决上述痛点的方案。

那么问题来了，微服务架构多“微”才合适?

行业内有这样四类常见实践。

实践一：统一服务层

这是最粗犷的玩法，所有基础数据，都通过一个统一的服务来进行访问。

在业务不是特别复杂的时候，这不失为一个快速分层的方案，一旦业务变得复杂，服务层会变得非常重，成为耦合焦点。

以微信场景为例，假设通过一个通用的服务层来访问基础数据。

则只有一个统一的服务层，用户信息，好友信息，群组信息，消息信息都通过这个服务层来访问。

实践二：一个子业务一个服务

如果所有的数据访问都通过一个服务层来访问，那么一行代码出故障，就将影响整个服务，所以更合理的做法是在服务层进行拆分。

服务层架构如何细分?

垂直拆分是个好的方案，将子业务分拆，那么微信的服务化架构或许会变成下面的样子：

这样的话，一个服务出问题也不会影响其他服务，与此同时，数据层也按照业务垂直拆分开了。

服务粒度变细之后，出现一个新的问题，业务与服务的连接关系变复杂了，有什么好的优化方案么?

常见的，加入一个高可用服务分发层(Service Mesh不就是这么干的么)，并在协议设计时加入服务号，可以减少蜘蛛网状的依赖关系：

实践三：一个数据库对应一个服务

数据访问服务最初是从DAO/ORM的数据访问需求过来的，所以有些公司也有一个数据库一个服务的玩法。

一个子业务对应一个服务的玩法如下图：

拆分成一个数据库一个服务，则架构会变成下面的样子：

群信息库，群成员库，群消息库之间也解耦开，不会相互影响。

实践四，一个接口对应一个服务

微服务架构中，更极端的，甚至一个接口对应一个微服务。

这样的话，架构就从：

进化为：

多个服务操纵同一个数据库，任何接口服务出问题，都不会影响其他接口服务。使用这种方案的，一般与开发语言特性结合比较紧密，例如golang。

上文中谈到的服务化与微服务，不同粒度的服务化各有什么优劣呢?

总的来说，细粒度拆分的优点有：

细粒度拆分的不足也很明显：

互联公司，以“子业务”作为微服务粒度是最常用，订单服务，用户服务，支付服务等等。

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：快上网

成都快上网为您推荐相关内容