美文网首页
架构应用(10),SOA&微服务

架构应用(10),SOA&微服务

作者: 可乐爱上咖啡 | 来源:发表于2018-11-25 22:15 被阅读34次

    一、面向服务的架构 SOA

    SOA 提出的背景是企业内部的 IT 系统重复建设且效率低下。

    SOA产生的背景:

    • 企业各部门有独立的 IT 系统,这些系统可能都涉及人员管理,各 IT 系统都需要重复开发人员管理的功能。

    • 随着业务的发展,复杂度越来越高,更多的流程和业务需要多个 IT 系统合作完成。

    • 各个独立的 IT 系统可能采购于不同的供应商,实现技术不同,企业自己也不太可能基于这些系统进行重构。

    SOA 提出了 三个关键概念:

    服务,所有业务功能都是一项服务, 服务就意味着要对外提供开放的能力。服务可大可小, 可简单也可复杂。

    ESB,将企业中各个不同的服务连接在一起,SOA 使用 ESB 来屏蔽异构系统 对外提供各种不同的接口方式, 以此来达到服务间高效的互联互通。

    松耦合,松耦合的目的是减少各个服务间的依赖和互相影响 。

    典型的 SOA 架构

    SOA 最广为人垢病的就是 ESB, ESB 需要实现与各种系统间的协议转换、数据转换、透明的动态路由等功能 。ESB 要完成这么多协议和数据格式的互相转换,工作量和复杂度都很大,而且这种转换是需要耗费大量计算性能的,当 ESB 承载的消息 太多时, ESB 本身会成为整个系统的性能瓶颈 。

    二、微服务

    提到微服务,都会跟SOA进行对比。我们看一些常见的对比观点:

    • 微服务是 SOA 的实现方式,SOA 是一种架构理念,而微服务是 SOA 理念的一种具体实现方法。

    • 微服务是去掉 ESB 后的 SOA。

    •微服务是一种和 SOA 相似但本质上不同的架构理念,认为微服务和 SOA 只是有点类似,但本质上是不同的架构设计理念。

    对比一下 SOA 和微服务:

    1.服务粒度:SOA 的服务粒度要粗一些,而微服务的服务粒度要细一些。

    2.服务通信:SOA 采用了 ESB 作为服务间通信的关键组件,负责服务定义、服务路由 、消息转换、 消息传递,总体上是重量级的实现。微服务推荐使用统一 的协议和格式,例如,阻STful 协议、盯C 协议,无须 ESB 这样的重量级实现。

    3.服务交付:SOA 对服务的交付并没有特殊要求,SOA 更多考虑的是兼容己有的系统;微服务的架构理念要求“快速交付飞相应地要求采取自动化测试、持续集成、自动化部署等 敏捷开发相关的最佳实践 。

    4.应用场景:SOA 更加适合于庞大、 复杂、异构的企业级系统;微服务更加适合于快速、轻量级、基于 Web 的互联网系统,这类系统业务变化快,需 要快速尝试、快速交付。

    微服务的精华,也是微服务与 SOA 的本质区别:

            small 服务细粒度、 lightweight 通信轻量级、automated 持续交付

    微服务有哪些坑:

    • 服务划分过细,服务间关系复杂。

    • 服务数量太多,团队效率急剧下降。(康威定律)

    • 调用链太长,性能下降,问题定位困难。

    • 没有自动化支撑,无法快速交付。

    • 没有服务治理,微服务数量多了后管理混乱 。服务路由,故障隔离,注册和发现。

    微服务最佳实践:

    1.拆分粒度,“两个披萨”理论(每个团队的人数不能多到两个披萨都不够吃的地步);“ 三个火枪手”的微服务拆分粒度原则,即 一个微服务三个人负责开发 。

    当我们在实施微服务架构时,根据团队规模来划分微服务数量 ,如果业务规继续发展,团队规模扩大,我们再将己 有的微服务进行拆分 。 例如,团队最初有 6 个人,那么可以划分为 2 个微服务。

    2.拆分方法

    (1)基于业务逻辑拆分。

    将系统中的业务模块按照职责范围识别出来,每个单独的业 务模块拆分为一个独立的服务。

    (2)基于可扩展拆分。

    将系统中的业务模块按照稳定性进行排序,将己经成熟和改动不大的服务拆分为稳定服务, 将经常变化和法代的服务拆分为变动服务。稳定的服务粒度可以粗一些,即使逻辑上没有强关 联的服务,也可以放在同一个子系统中。

    (3)基于可靠性拆分。

    将系统中的业务模块按照优先级排序,将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来,然后重点保证核心服务的高可用。

    基于可靠性拆分带来的好处:避免非核心服务故障影响核心服务,核心服务高可用方案可以更简单,能够降低高可用成本。

    (4)基于性能拆分。

    将性能要求高或性能压力大的模块拆分出来,避免 性能压力大的服务影响其他服务。

    以上几种拆分方式不是多选 1 ,而是可以根据实际情况自由排列组合。

    微服务的基础设施

    微服务基础设施

    微服务并不是很多人认为的那样又简单又轻量级。要做好微服务,这些基础设 施都是必不可少的 , 否则微服务就会变成一个焦油坑,让业务和团队在里面不断挣扎而无法自拔。

    微服务并没有减少复杂度,而只是将复杂度从 ESB 转移到 了 基础设施 。 我们可以看到,“服务发现”“服务路由”等其实都是 ESB 的功能,只是在微服务中剥离出来成 了独立的基础系统。

    我需要一个高并发的架构,我的系统要改造成微服务吗?

    https://yq.aliyun.com/articles/623271?utm_content=m_1000011884

    相关文章

      网友评论

          本文标题:架构应用(10),SOA&微服务

          本文链接:https://www.haomeiwen.com/subject/ocqpfqtx.html