一、单体式框架
最开始我们的应用都是放在一台机器上的，随着业务的增长，单体式存在硬件受限和一个故障可能整个停掉的风险，这里改进方式就是分布式系统，其实微服务框架是分布式的一种，下面介绍下微服务框架
二、微服务框架
1、
对于单体式的出现的问题，微服务的解决思想就是拆分，拆分的维度有三个：
负载
实现的是多web服务器
功能
以不同职能/服务划分，划分标准可能是用例或资源
数据库
通过分表的形式，将数据hash到不同的数据库上
PS：这里简单说下哈希数据，它的数据形式是key-value，以多个redis sever为例，如果有key1/key2/key3，如果只有一个sever则直接将所有key放入，如果有两个sever则通过hash函数将key进行映射，看映射在【sever1,sever2】区间的哪里，这里采用顺序查表的方式，分别将key映射到sever上，对于增加节点的话也是顺序查找，比如加了key4可能只是key发生了变化，其他key不用动，即使新增或者挂掉服务器也不会影响全部，只要根据hash顺时针定位就可以了，对于数据发生变化各节点同步是通过一致性哈希来实现的。
2、
处理的问题
通信
对于C/S端通信，中间增加了API gateway（API网关主要是用来同意接入服务的）
对于内部通信：一是http(主要框架是REST/RPC，对于后者我们很熟悉了)；二是队列（AMQP代表是kafka）
3、
优点：
微服务可以实现独立部署
独立扩展，主要是维护相互可用和通信
三、分布式框架
1、简介
我们集群应用的就是分布式卡框架，主要是实现多台机器的同步可用。整体是一个集群每个机器是其中的节点应用分布在节点上，彼此应用间的通信利用的是TCP模块和远程通信框架RPC
2、关键点
主要考虑的是性能、容错和通信。很容易理解比如应用层的故障，经常会有挂掉重启等故障，主要是想考察剩余节点是否能扛住流量的情况，这就是对性能和容错性的一种考察。对于通信的问题，长出现的故障数据传输的丢失（丢包）、网络卡住了（网络延迟）、服务器缓慢等等，也要注意之前说到的节点熔断现象
网友评论