一.单体架构和微服务架构的比较
1.单体架构的优势和不足
单体架构的优势:在项目的初期便于开发、便于测试、便于部署
单体架构的不足:
什么是横向扩展和垂直扩展?
1)横向扩展
也叫 水平扩展
,用更多的节点支撑更大量的请求。 如成千上万的蚂蚁完成一项搬运工作
2)纵向扩展
又叫 垂直扩展
,扩展一个点的能力支撑更大的请求。如利用1个人的能力,如蜘蛛侠逼停火
2.什么是微服务架构?
微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。
将单体应用拆分成多个高内聚低耦合的小型服务,每个小型服务运行在独立进程当中,由不同的团队开发和维护,服务间采用轻量级通信机制,
独立自动部署,可以采用不同的语言以及存储。
3.微服务架构的优势
二、微服务所要解决的主要问题
1.服务的拆分
2.数据一致性
比如下单和扣减库存应该是在一个事务中,但是微服务中下单和扣减库存是在不同的服务器上,这就需要分布式事务进行辅助,分布式事务就有延时性高,nosql不支持等这些缺点,这些缺点导致分布式事务无法应用到微服务中。
实现最终一致性有两种模式:
1).用消息队列实现可靠性模式
2).补偿模式-sagas模式
在微服务的初期尽量粗粒度,将事务放在一个服务中。
这两种方式都需要写大量的代码,而且目前没有较好的框架
3.服务通信
4.服务网关
并且植入到每个微服务业务代码中,这就造成业务代码和身份认证代码耦合,降低代码的复用性。
在身份认证、路由服务等放在服务网关中,向业务代码中屏蔽这些网络边界的细节,使得业务服务专注于业务逻辑的开发。
比如将多个服务的数据聚合在一起返回给前端
5.高可观察
微服务整个系统都需要在我们的监控体系中,包括注册中心的监控、 服务进程的监控、流量的监控、日志的监控,状态的监控等
将这些信息集中以图表的形式输出,方便查看问题。
比如说在电商app中,我们无法进行下单操作,在分布式服务架构中 ,日志是散落在多个服务上的,我们如果说登录每台服务器进行检索是非常低效的,这就需要我们进行日志格式的标准化,并利用一定的手段将日志聚合起来进行检索查询,我们需要将这些检索查询的组件放到共享库当中,或者代码脚手架进行提供,以方便我们和业务代码进行解耦。
在微服务场景中,一个客户端发起的请求要经过多个服务的调用,我们不知道该请求经历哪些服务的调用,调用哪些服务出现了问题,每个服务的输入输出是什么,这都给我们定位问题带来的困难;除此之外如果一个请求耗时挺长,我们不知道哪个服务耗时最长,这就给我们性能优化带来了困难。随着架构的演进,我们需要知道服务之间的依赖关系,这就需要我们的分布式追踪。
6.可靠性
但是可能因为一个服务不可用导致上游服务线程服务夯死,故障进一步向上传播。
这个地方线程服务夯死是指的是服务不断占用资源,导致其他服务线程无法正常工作。
仓壁隔离:给每个应用分配一个独立的线程池,而不是共享线程池,这样一个应用的故障不会拖累其他服务。
熔断:是指服务调用在一定的时间内达到一定的数量,自动关闭该服务的调用开关,改为返回错误,这样降低资源耗尽的风险
服务降级:当服务不可用时,服务消费者应该对接口编写降级方法,
比如评论服务在获取用户服务的头像时,用户服务不可用,那么降级方法可以返回默认头像,或者缓存中的头像,
比如推荐服务不可用时,网关服务右边栏的页面使他为空,不展示任何信息。
幂等重试:服务间通讯是通过网络传输的,网络异常和网络分区故障,就会经常出现,我们遇到这种情况就可以进行调用的重试,重试时要注意:
接口必须是幂等,无论运行一次或者多次,最终结果必须相同,幂等性保证重试不会产生负面的影响,在重试过程中休眠时间应该是指数增长。
否则会产生鲸群效应,比如故障后的服务上线后,如果有大量的服务在同一个重试窗口内重试,此时很容易给系统造成巨大的压力。
要实现这些要实现一个断路器,Netflix提供的hystrix是比较适合的。
三、SOA和微服务的比较
SOA:ESB、SOAP
微服务:轻量级MQ、REST、RPC
SOA:共享数据库
微服务:一服务一数据库
SOA:服务粒度比较粗,多个单体的组合
微服务:粒度更小的服务
参与评论
手机查看
返回顶部