当前位置： 移动技术网 > IT编程>开发语言>Java > 初识微服务

初识微服务

2018年05月03日  | 移动技术网IT编程  | 我要评论

一.单体架构和微服务架构的比较

1.单体架构的优势和不足

单体架构的优势：在项目的初期便于开发、便于测试、便于部署

单体架构的不足：

  • 复杂性高-代码难以理解，难以修改和重构
  • 交付效率低-项目整体部署耗时长、难以定位问题、影响范围广、风险大、发布频次低
  • 伸缩性差-单体只能按整体进行横向扩展，无法分模块垂直扩展；IO密集型模块（日志收集）和cpu密集型模块（图片压缩、加解密）无法独立扩容和升级
  • 可靠性差-一个bug有可能引起整个应用的崩溃
  • 受技术栈限制，团队只能使用同一个语言和框架

什么是横向扩展和垂直扩展？

1）横向扩展 也叫 水平扩展，用更多的节点支撑更大量的请求。 如成千上万的蚂蚁完成一项搬运工作

2）纵向扩展 又叫 垂直扩展，扩展一个点的能力支撑更大的请求。如利用1个人的能力，如蜘蛛侠逼停火

 

2.什么是微服务架构?

微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。

 将单体应用拆分成多个高内聚低耦合的小型服务，每个小型服务运行在独立进程当中，由不同的团队开发和维护，服务间采用轻量级通信机制，

独立自动部署，可以采用不同的语言以及存储。

 

3.微服务架构的优势

  • 易于开发和维护-微服务相对小，易于理解，启动时间少，开发效率高
  • 独立部署-一个微服务的修改不需要协调其他服务　　
  • 伸缩性强-每个服务都可以进行横向和纵向扩展；每个服务都可以独立扩容
  • 技术异构性-各个微服务可以使用最适合该服务的技术

 

二、微服务所要解决的主要问题

1.服务的拆分

  • 微服务拆分的原则-高内聚低耦合、服务粒度适中
  • 拥有独立的数据库
  • 微服务之间确定服务边界

2.数据一致性

在单体架构中数据一致性可以通过事务实现，在分布式微服务中就无法实现，因为服务部署在不同的服务器上。
比如下单和扣减库存应该是在一个事务中，但是微服务中下单和扣减库存是在不同的服务器上，这就需要分布式事务进行辅助，分布式事务就有延时性高，nosql不支持等这些缺点，这些缺点导致分布式事务无法应用到微服务中。
 
在微服务中使用最终一致性来代替强一致性。
实现最终一致性有两种模式:
1）.用消息队列实现可靠性模式
2）.补偿模式-sagas模式
在微服务的初期尽量粗粒度，将事务放在一个服务中。
这两种方式都需要写大量的代码，而且目前没有较好的框架
 
3.服务通信
  • 通信技术方案-RPCvsRESTvs异步消息
  • 服务注册和发现
  • 负载均衡

4.服务网关

  • 身份认证、路由服务、流量控制、日志统计
如果我们的微服务和终端通信，势必要考虑身份认证，如果我们的微服务都与每个终端用户打交道，那么这些代码就需要拷贝多份，
并且植入到每个微服务业务代码中，这就造成业务代码和身份认证代码耦合，降低代码的复用性。
在身份认证、路由服务等放在服务网关中，向业务代码中屏蔽这些网络边界的细节，使得业务服务专注于业务逻辑的开发。
  • 为前端服务的后端

　　比如将多个服务的数据聚合在一起返回给前端

5.高可观察
  • 健康检查、集中监控

微服务整个系统都需要在我们的监控体系中，包括注册中心的监控、 服务进程的监控、流量的监控、日志的监控，状态的监控等 

将这些信息集中以图表的形式输出，方便查看问题。
  • 日志聚合及检索

比如说在电商app中，我们无法进行下单操作，在分布式服务架构中 ，日志是散落在多个服务上的，我们如果说登录每台服务器进行检索是非常低效的，这就需要我们进行日志格式的标准化，并利用一定的手段将日志聚合起来进行检索查询，我们需要将这些检索查询的组件放到共享库当中，或者代码脚手架进行提供，以方便我们和业务代码进行解耦。

  • 分布式追踪

在微服务场景中，一个客户端发起的请求要经过多个服务的调用，我们不知道该请求经历哪些服务的调用，调用哪些服务出现了问题，每个服务的输入输出是什么，这都给我们定位问题带来的困难；除此之外如果一个请求耗时挺长，我们不知道哪个服务耗时最长，这就给我们性能优化带来了困难。随着架构的演进，我们需要知道服务之间的依赖关系，这就需要我们的分布式追踪。

6.可靠性

  • 流量控制，超时控制
  • 仓壁隔离，熔断机制
在单体架构中，可能因为一个服务不可用导致整个系统不可用。微服务不会产生这种情况，一个微服务不可用时不会影响和它没有依赖关系的服务，
但是可能因为一个服务不可用导致上游服务线程服务夯死，故障进一步向上传播。
这个地方线程服务夯死是指的是服务不断占用资源，导致其他服务线程无法正常工作。
 
仓壁隔离：给每个应用分配一个独立的线程池，而不是共享线程池，这样一个应用的故障不会拖累其他服务。
熔断：是指服务调用在一定的时间内达到一定的数量，自动关闭该服务的调用开关，改为返回错误，这样降低资源耗尽的风险
 
  • 服务降级，幂等重试
服务降级：当服务不可用时，服务消费者应该对接口编写降级方法，
比如评论服务在获取用户服务的头像时，用户服务不可用，那么降级方法可以返回默认头像，或者缓存中的头像，
比如推荐服务不可用时，网关服务右边栏的页面使他为空，不展示任何信息。
 
幂等重试：服务间通讯是通过网络传输的，网络异常和网络分区故障，就会经常出现，我们遇到这种情况就可以进行调用的重试，重试时要注意：
接口必须是幂等，无论运行一次或者多次，最终结果必须相同，幂等性保证重试不会产生负面的影响，在重试过程中休眠时间应该是指数增长。
否则会产生鲸群效应，比如故障后的服务上线后，如果有大量的服务在同一个重试窗口内重试，此时很容易给系统造成巨大的压力。
要实现这些要实现一个断路器，Netflix提供的hystrix是比较适合的。

 

三、SOA和微服务的比较

  • 技术栈

SOA：ESB、SOAP

微服务：轻量级MQ、REST、RPC

  • 数据拆分

SOA：共享数据库

微服务：一服务一数据库

  • 服务粒度

SOA：服务粒度比较粗，多个单体的组合

微服务:粒度更小的服务

您可能感兴趣的文章:

如对本文有疑问， 点击进行留言回复！！

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网