业界对于可扩展系统架构设计有一个朴素的理念:通过加机器就可以解决容量和可用性问题。
微服务
快速开发迭代
自动化部署
独立部署
错误隔离
负载均衡
容错处理 (熔断, 降级)
链路跟踪
服务发现,服务治理
动态扩容
中心化
服务 API
1,基于不同的业务拆分
Y轴扩展会将庞大的整体应用拆分为多个服务,每个服务实现一组相关的功能,如订单管理、客户管理等。在工程上常见的方案是服务化架构(SOA),比如对于一个电子商务平台,我们可以拆分成不同的服务,组成类似下面的架构:、
但通过上图可以发现,当服务数量增多时,服务调用关系变得复杂,为系统添加一个新功能,要调用的服务数变得不可控,由此引发了服务管理上的混乱,所以一般情况下,需要采用服务注册的机制形成服务网关来进行服务治理
2. 服务与数据的优先级划分
Z轴扩展通常是指基于请求者或用户独特的需求,进行系统划分,并使得划分出来的子系统相互隔离但又是完整的。以生产汽车的工厂来举例:福特公司为了发展在中国的业务,或者利用中国的廉价劳动力,在中国建立一个完整的子工厂,与美国工厂一样,负责完整的汽车生产。这就是一种Z 轴扩展。
工程领域常见的Z轴扩展有以下两种方案
1,单元化架构
在分布式服务设计领域,一个单元Cell就是满足某个分区所有业务操作的自包含闭环。如上面我们说到的Y轴扩展的SOA架构。客户端对服务端节点的选择一般是随机的,但是,如果在此上加Z轴扩展,那服务节点的选择将不再是随机的,而是每个单元自成一体。
2,数据分区
为了性能数据安全上的考虑,我们将一个完整的数据集按一定维度划分出不同的子集。一个分区(Shard),就是整体数据集的一个子集。比如用尾号来划分用户,那同样尾号的那部分用户就可以认为是同一个分区,数据分区一般包括以下几种数据划分形式:
数据类型:如业务类型
数据范围:如时间段、用户ID
数据热度:如用户活跃度、商品热度
按读写分:如商品描述、商品库存
3. 无状态服务
对于无状态服务,首先说一下什么是状态:如果一个数据需要被多个服务共享,才能完成一笔交易,那么这个数据被称为状态。进而依赖这个状态的服务被称为有状态的服务,反之成为无状态服务。
这个无状态服务原则并不是说在微服务架构里不允许存在状态,表达的真实意思就是要把有状态的业务服务改变为无状态的计算类服务,那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
场景说明:例如我们从前在本地内存中建立的数据缓存、Session缓存,到现在微服务架构中就应该把数据迁移到分布式缓存中存储,让业务服务变成一个无状态的计算节点。迁移后,就可以做到按需动态伸缩,微服务应用在运行时动态增删节点,就不再需要考虑缓存数据如何同步的问题。
方案
1、undertow替换tomcat
电子商务类型网站大多都是短请求,一般响应时间都在100ms,这时可以将web容器从tomcat替换为undertow,下面介绍下步骤:1、增加pom配置
<dependency>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-starter-web</artifactid>
<exclusions>
<exclusion>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-starter-tomcat</artifactid>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-starter-undertow</artifactid>
</dependency>
2、增加相关配置
server:
undertow:
direct-buffers: true
io-threads: 4
worker-threads: 160
2、缓存
将部分热点数据或者静态数据放到本地缓存或者redis中,如果有需要可以定时更新缓存数据
3、异步
在代码过程中我们很多代码都不需要等返回结果,也就是部分代码是可以并行执行,这个时候可以使用异步,最简单的方案是使用springboot提供的@Async注解,当然也可以通过线程池来实现,
4、业务拆分
5、集成消息队列
有很多场景对数据实时性要求不那么强的,或者对业务进行业务容错处理时可以将消息发送到kafka,然后延时消费。