首页 > 其他分享 >关于 分布式和微服务 的一些总结

关于 分布式和微服务 的一些总结

时间:2022-12-12 17:08:33浏览次数:66  
标签:总结 架构 扩展 应用程序 分布式系统 服务 分布式


写在前面


  • 一直对微服务和分布式这两个概念模凌两可,不是太清晰,而且接触的项目也没这么大体量,没有用到过,所以蹭现在有时间总结一下,总结很大部分来源于《从Paxos到Zookper分布式一致性原理与实践》和《微服务架构设计模式》这两本书里。
  • 嗯,关于分布式系统和微服务架构的一些拙见,因为大家一直放到一起讲,所以总结一波。
  • 博文中理解有所欠缺的小伙伴请留言,多多指教。

拿着爸妈提供的物质,见识他们没有见识过的世面,体验他们没有体验过的人生,到头来,却嫌弃他们如此笨拙。


一、名词解释

分布式系统

个人觉得​​分布式系统​​​面向的是​​Ops​​​,更多的是考虑​​系统性能和部署环境​​​之间的问题,通过分布式解决在没有​​大型主机的部署环境​​​情况下,​​系统性能的高可用和吞吐量​​​,是个一个很早就提出来的一个概念,是由​​集中式系统​​​过渡来的,随着计算机系统向​​网络化​​​和​​微型化​​​的发展日趋明显,同时​​业务的发展​​​,传统的​​集中式​​处理模式越来越不能适应人们的需求,学习成本高,大型主机贵、容错性差,扩容困难。

为了解决业务快速发展给IT系统带来的巨大挑战,从2009年开始,阿里集团启动了去IOE计划,其电商系统开始正式迈入​​分布式系统时代​​。

在​​《分布式系统概念与设计》​​​生一书中,对​​分布式系统​​做了如下定义:

分布式系统​​是一个​​硬件或软件组件​​​分布在不同的​​网络计算机​​​上,彼此之间​​仅仅​​​通过​​消息传递​​​进行​​通信和协调​​​的系统。 (硬件或软件组件,个人理解 ,硬件组件分布我们可以结合​​HarmonyOS​​理解,音画同步,应用跨设备流转,软总线等硬件抽象的分布式,或者可以结合RAID(独立冗余磁盘阵列)理解,可以理解为以机器为粒度的磁盘阵列,软件组件分布这里结合我们常说的微服务分布式部署,类比java Web分布式系统。)

微服务架构

​微服务 (Microservices)​​​ 是一种​​软体架构风格​​​,它是以专注於​​单一责任​​​与功能的​​小型功能区块​​​ (Small Building Blocks) 为基础,利用​​模组化​​​的方式组合出复杂的大型应用程式,​​各功能区块使用与语言无关​​​ (Language-Independent/Language agnostic) 的​​API 集相互通讯​​​。 微服务的起源是由 ​​Peter Rodgers​​​博士于 2005 年度云端运算博览会提出的​​微 Web 服务​​​ (Micro-Web-Service) 开始,​​Juval Löwy​​​则是与他有类似的前导想法,将类别变成细粒服务 (granular services),以作为 Microsoft 下一阶段的软体架构,其核心想法是让服务是由类似​​Unix 管道​​​的存取方式使用,而且复杂的服务背后是使用简单 ​​URI 来开放介面​​​,任何服务,任何细粒都能被开放 (exposed)。这个设计在 ​​HP​​​的实验室被实现,具有改变复杂软体系统的强大力量。 2014年,​​Martin Fowler​​​与​​James Lewis​​​共同提出了​​微服务​​​的概念,定义了​​微服务​​​是由以​​单一应用程式构成的小服务​​​,自己拥有自己的​​行程​​​与​​轻量化处理​​​,服务依业务功能设计,以​​全自动的方式部署​​​,与其他服务使用​​HTTP API 通讯​​​。同时服务会使用​​最小的规模​​​的​​集中管理 (例如 Docker) 能力​​​,服务可以用不同的​​程序语言​​​与​​资料库​​等元件协作。

个人觉得​​微服务​​​架构更多的是面向​​dev​​​,更多的是考虑​​编码和项目业务之间​​​的问题,根据​​功能​​​把​​应用拆分为服务​​​。解决的是​​开发问题和应用复杂性​​​,是在对于业务的快速发展中​​单体应用​​​不能满足需要的时候,提出来的一个概念,​​《微服务架构设计模式》​​一书中对微服务架构做如下定义:

把应用程序​​功能性分解​​​为​​一组服务​​​的架构风格。(很直白的一句话,不需要多解释,对于大型系统而言,模块化是必不可少的,相信小伙伴也做过类似的项目,​​微服务架可以看做是模块化的一种形式​​)

二、比较

从应用程序的扩展角度考虑

​微服务​​​和​​分布式​​​都是对​​大型应用程序的扩展​​​,只是​​扩展方向​​不同:

  • 分布式系统更多是偏​​水平扩展​​​,在​​ops​​​方面的解决办法,利用​​部署系统环境的空间分布性​​​,比如​​SOA架构​​​中利用分布式集成大型、复杂的单体应用程序;比如对​​实例进行克隆​​​,以​​副本​​​的形式对应用的数据和服务提供一种冗余方式(数据副本和服务副本),从而对外​​提供高可用,高并发的服务​​​。分布式需要解决​​分布式数据一致性​​​以及分布式环境​​通信异常​​​、​​网络分区​​​等问题。比如通过​​Zookeeper​​解决分布式数据一致性的问题。分布式系统可以理解为以解决硬件层面的压力从而对应用进行扩展。
  • 微服务架构更多的是​​垂直方向​​​的扩展,在​​dev​​​方面解决问题,利用​​应用程序的功能性分解,,把应用拆分为一组服务​​​,每个服务负责特定的功能。每个服务都​​相对较小并容易维护​​​,使大型的复杂应用程序可以​​持续交付和持续部署​​​。服务可以​​独立部署​​​、可以​​独立扩展​​​。同时微服务架构可以实现​​团队的自治​​​。更容易实验和采纳​​新的技​​​术。更好的​​容错性​​​。即​​服务之间松耦合​​​,但是单​​个服务又是高内聚​​的。微服务架构可以理解为解决软件层面的压力对应用进行扩展。

微服务架构和分布式系统之间的关系

个人认为,​​不属于包含关系​​​,都是是对于​​应用扩展​​​的不同解决办法。一般情况下,​​微服务架构的应用一般为分布式系统。但分布式系统不一定是微服务架构​​。


嗯,时间原因,先写这么多,之后会查查论文啥的,在做详细分析。

​http://www.sstir.cn/search/list?keyword=%E5%BE%AE%E6%9C%8D%E5%8A%A1​


标签:总结,架构,扩展,应用程序,分布式系统,服务,分布式
From: https://blog.51cto.com/u_13474506/5931155

相关文章