微服务架构整理-(一、微服务架构的发展)
微服务架构的发展单体应用架构垂直应用架构分布式架构功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能,丰富你的文章UML 图表FLowchart流程图导出与导入导出导入工作中常用到微服务架构
工作中常用到微服务架构,知识点零零散散,这里稍微整理一下。
微服务架构的诞生是建立在各代程序员的努力之下,先后经历了单体应用架构、垂直应用架构以及分布式应用架构,并非一朝一夕。
单体应用架构
此架构是将所有的功能集成于一个服务中,即最终会打包成一个具体的应用,例如jar,war。每个项目包括每一层每一块里编写所有的代码。例如一个web工程里面包括了前端页面,web层代码,Service层代码,DAO层代码,把这些代码打包到一个项目当中,放到web容器中启动。如图所示:
优点
开发简单,适用于小型应用
缺点
显然,这种架构易于开发、维护和部署。在用户量不多的情况下,该架构完全可以满足需求,但一旦用户量以及业务的复杂化,再加上代码的高度耦合,系统的维护和横向扩展异常困难。当用户量达到需要负载均衡来支持时,不得不使用多台服务器,但并不是应用中的每个功能模块都需要负载均衡,因此在扩展时必然会导致资源的浪费。例如:订单管理模块每秒访问1k次,用户管理每秒200次,这时扩展时连带用户管理一起扩展了,意义不大。总而言之,单体不易扩展与维护,代码的耦合度高。
垂直应用架构
由于单体应用架构的种种问题,先辈们开始考虑将各功能模块抽取成独立的子工程,每个子工程跑在一个容器中。例如:
如果用户中心访问较多,只需要针对用户中心进行扩展就可以了。
优点
解决了高并发问题
可针对不同的模块进行优化
方便水平扩展
容错性高(其中一个系统出现了问题了,不影响其他系统,只需要针对出错的系统进行停机维护即可)
缺点
系统之间相互独立:需要为相互作用系统建立联系
大量的重复工作
分布式架构
把一个垂直应用进行业务上的抽取,抽取成两部分内容。一个是基础服务,另一个是业务功能,通过业务功能去调用相应的基础服务就构成了分布式应用。这样就很好的解决了服务与服务之间的调用。例如:
优点
解决了服务与服务之间调用的问题,即减少了服务与服务之间的耦合度
缺点
随着服务层体积的增大,应用越来越多,服务的评估,治理与统一治理越来越难
面向服务的架构(SOA)
针对分布式架构缺点,形成了SOA(Service-Oriented Architecture)概念,即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
站在功能的角度,把业务逻辑抽象成可利用、可组装的服务,通过服务的编排实现业务的快速再生,目的:把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速利用。比较流行的SOA有ESB,DUBBO。
优点
抽取公共的功能为服务,提高开发效率
对不同的服务进行集群化部署解决系统压力
基于ESB/DUBBO进一步减少了系统的耦合
缺点
抽取服务的粒度较大
虽然基于ESB/DUBBO进一步减少了系统的耦合,但是耦合还是存在的,且不低
微服务架构
针对SOA的缺点,新的一种架构诞生了,即微服役架构。通过对服务尽可能的拆分,直到不能拆分为上并独立打包运行,服务调用层与服务提供方通过轻量级的http协议进行交互,达到完全解耦的效果,每次交互只需要一个简单的http请求即可,无需复杂的调用技术。每个服务遵循单一职责原则,通过http接口向外提供功能。
优点
通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将缩短,运维成本也奖大幅度下降
微服务遵循单一职责原则,采用restful等轻量级协议传输
缺点
微服务过多,服务治理成本高,不利于系统维护
分布式系统开发的技术成本高(容错、分布式事物等)
SOA与微服务之间的关系
SOA它是一种设计方法,其中包含多个服务,服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。
微服务架构 和SOA类似,它是在SOA基础上的升华,强调的重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分成多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
功能 | SOA | 微服务 |
---|---|---|
组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
耦合度 | 通常松耦合 | 总是松耦合 |
公司架构 | 任何类型 | 小型、专注于功能交叉团队 |
管理 | 着重中央管理 | 着重分散管理 |
目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
调用方式 | RPC(较重) | HTTP(较轻) |
总之,微服务的发展不是一朝一夕,也是经过多年的迭代,最终成为广受欢迎的架构。
更多推荐
所有评论(0)