架构杂谈《二》

架构杂谈《二》

 

服务化到微服务

1、微服务的产生html

  随着互联网企业的不断发展,海量用户发起的大规模、高并发请求是企业不得不面对的,上一篇 架构杂谈《一》杂谈的SOA服务化系统可以分解任务,让每一个服务更简单、职责单1、更易于扩展。但不管是Web Service 仍是ESB,都有时代遗留下的问题。数据库

  Web Service缓存

   1)依赖中心化的服务发现机制服务器

   2)使用SOAP通信协议,一般使用XML格式来序列化通讯数据,XML格式的数据冗余太大,协议过重网络

   3)服务化管理和治理设施并不完善架构

  ESB并发

   1)ESB 虽然是SOA实现的一种方式,却更多地体现了系统集成的便利性,经过统一的服务总线将各个服务组合在一块儿运维

        2)组合在ESB上的服务自己有多是一个臃肿的服务分布式

   3)系统内部的复杂性仍然存在。ESB试图经过总线来掩盖系统内部的复杂性模块化

        4)对于总线自己中心化的管道模型,系统变动时影响的范围会随之扩大

出现问题解决问题是人类进步的阶梯,对于软件架构也是同样,近年来服务架构设计获得了进一步的演化和发展,微服务架构已经出如今不一样公司的讨论、设计和实践中,通过市场检验的东西确定会被你们所接受。

  微服务架构提倡将软件应用设计成多个可独立开发、配置、运行和维护的子服务,子服务之间经过良好的接口定义通讯机制,一般使用RESTful风格的API形式来通讯。由于RESTful 风格的 API 一般是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的, HTTP协议有跨语言、跨异构系统的优势, 固然也可经过底层的二进制协议、消息队列协议等进行交互。这些服务不须要中心化的统一管理,每一个服务的功能可自治,而且可由不一样的语言、系统和平台实现 。 

  微服务架构致力于松耦合和高内聚的效果,与SOA和ESB相比,再也不强调服务总线和通讯机制的多样性,一般经过RESTful 风格的API和轻量级的消息通讯协议来完成。

微服务架构并非为了拆分而拆分,真正的目的是经过对微服务进行水平扩展解决传统的单体应用在业务急剧增加时遇到的问题,并且因为拆分的微服务系统中专业的人作 专业的事,人员和项目的职责单1、低藕合、高内聚,因此产生问题的几率就会降到最小。

2、微服务与单体的对比

 

(微服务架构图)

从上图能够获得:

  1)  微服务把每个职责单一的功能放在一个独立的服务中

  2)  每一个服务运行在一个单独的进程中

  3)  每一个服务有多个实例在运行,每一个实例能够运行在容器化平台内

  4)  每一个服务有本身的数据存储,实际上,每一个服务应该有本身独享的数据库、缓存、消息队列等

  5)  每一个服务均可根据性能需求独立地水平伸缩

 

(单体架构图)

经过对比,能够获得传统单体架构的特色:

  1)  传统单体架构将全部模块化组件糅合后运行在同一个服务的进程中

  2)  某个模块发生变动时,须要将全部的模块编译、打包上线

  3)  长此以往,模块间的依赖将会不清晰,互相耦合,互相依赖成为常态

经过将两种架构对比来看,微服务架构更加的灵活而且可水平伸缩,可让专业的人干专业的事。

3、微服务与SOA服务的对比

  微服务架构的一些特色与 SOA 服务化架构类似, 事实上微服务架构与 SOA 服务化架构并不冲突,它们一脉相承,微服务架构是服务化架构响应特定历史时期的使用场景的延续,是服务化进行升华井落地的一种实现方式。 SOA 服务化的理念在微服务架构中仍然有效,微服务在 SOA 服务化的基础上进行了演进和叠加,造成了适合现代化应用场景的一个方法论。

通过几十年互联网的高速发展,以及敏捷、持续集成、持续交付、DevOps、云技术等的深刻人心,服务架构的开发、测试、部署以及监控等,相比SOA已经发生大的变化。

  1)  SOA 服务化涉及的范围更广一些,强调不一样的异构服务之间的协做和契约 ,并强调有效集成、业务流程编排、历史应用集成等,典型表明为 Web Service 和 ESB

  2)  微服务使用一系列的微小服务来实现总体的业务流程,目的是有效地拆分应用,实现敏捷开发和部署,在每一个微小服务的团队里,减小了跨团队的沟通,让专业的人作专业的事,缩小变动和法代影响的范围,并达到单一微服务更容易水平扩展的目的

  3)  微服务将完整的应用拆分红多个细小的服务,一般使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理 , 每一个微服务运行在单一的进程内,微服务中的部署互相独立 、 互不影响。

  4)  SOA 服务化一般将多个业务服务经过组件化模块方式打在一个包里,而后统一部署在一个应用服务器上。

  6)  SOA 对粒度没有要求 , 在实践中服务一般是粗粒度的,强调接口契约的规范化,内部实现能够更粗粒度。

相比SOA的服务实现方式,微服务更具灵活性、可实施性以及可扩展性,其强调的是一种独立测试、独立部署、独立运行的软件架构模式。对于微服务的概念而言,它是SOA的一个子集,而对于其实现方式而言,它是一种更符合现代化互联网发展趋势的实践,是一种更容易帮助企业或组织有效并成功实施的服务架构。

总结

最后让我来总结下微服务架构的主要特色

  • 将传统单体应用拆分红网络服务,来实现模块化组件 。
  • 根据微服务架构的服务划分来分组职能团队,减小跨团队的沟通 。
  • 每一个服务对应一个团队,团队成员负责开发、测试、运维和运营 ,开发后在团队内运维和运营,不须要交付给其余团队。
  • 去中 心化、 去 SOA 服务化的中 心服务治理和去企业服务总线 。
  • 微服务重视服务的合理拆分、分层和构造,可建设自动化持续发布平台,井进行敏捷开发和部署。

 说明:

  一、文中的图都来自于百度图片

  二、参考书籍:《分布式服务架构:原理、设计与实战》

  三、若有不合适的地方请反馈。综合后更改。

相关文章
相关标签/搜索