要谈微服务,先说下单体式架构。比如索贝数码的非编剪辑系统,基本上是安装包安装在1台定制工作站(指定型号,防止不兼容等各类问题),一个主程序exe调用多个dll,采用微内核单体式架构。一般的工具软件多采用此结构,相当于客户端。当然也会部署几台工作主机,供主要主机调用,例如转码功能,部署一个集群。但主体功能都在主要主机上运行。
单体式架构,开发简单,但维护起来代价较大。多为开发彼此修改代码,互相影响,发版需同步,扩展性差,无法适应互联网环境,仅作为单节点单兵作战。正因为如此,有了分布式系统,以至于发展到微服务架构2.0,最新的sidecar等。
一 三维分解

X 轴扩展是扩展单体应用程序的常用方法。在负载均衡器之后运行应用程序的多个实例。负载均衡器在 N 个相同的实例之间分配请求。这是提高应用程序吞吐量和可用性的好方法

Z 轴扩展也需要运行单体应用程序的多个实例,但不同于 X 轴扩展,每个实例仅负责数据的一个子集。图 1-5 展示了 Z 轴扩展的工作原理。置于前端的路由器使用请求中的特定属性将请求路由到适当的实例。例如,应用程序可能会使用请求中包含的 userId 来路由请求。在这个例子中,每个应用程序实例负责一部分用户。该路由器使用请求 Authorization头部指定的 userId 来从 N 个相同的应用程序实例中选择一个。对于应用程序需要处理增加的事务和数据量时,Z 轴扩展是一种很好的扩展方式

X 轴和 Z 轴扩展有效地提升了应用的吞吐量和可用性,然而这两种方式都没有解决日益增长的开发问题和应用复杂性。为了解决这些问题,我们需要采用 Y 轴扩展,也就是功能性分解。Y 轴扩展把一个单体应用分成了一组服务

二 服务拆分策略



1万+

被折叠的 条评论
为什么被折叠?



