江苏龙网

  1. 首页 > 人文 > >

小小天看世界■一文带你彻底搞懂面试问的微服务、RPC、服务治理、下一代微服务( 二 )


微服务架构
合久必分 ， 鉴于「单体应用程序」有上述的缺点 ， 单个应用程序被划分成各种小的、互相连接的微服务 ， 一个微服务完成一个比较单一的功能 ， 相互之间保持独立和解耦合 ， 这就是微服务架构 。
微服务优点
相对于单体服务 ， 微服务有很多优点 ， 这里列举几个主要的好处
技术异构性
不同服务内部的开发技术可以不一致 ， 你可以用java来开发helloworld服务A ， 用golang来开发helloworld服务B ， 大家再也不用为哪种语言是世界上最好的语言而争论不休 。
小小天看世界■一文带你彻底搞懂面试问的微服务、RPC、服务治理、下一代微服务
文章图片
为不同的服务选择最适合该服务的技术 ， 系统中不同部分也可以使用不同的存储技术 ， 比如A服务可以选择redis存储 ， B服务你可以选择用MySQL存储 ， 这都是允许的 ， 你的服务你做主 。
隔离性
一个服务不可用不会导致另一个服务也瘫痪 ， 因为各个服务是相互独立和自治的系统 。 这在单体应用程序中是做不到的 ， 单体应用程序中某个模块瘫痪 ， 必将导致整个系统不可用 ， 当然 ， 单体程序也可以在不同机器上部署同样的程序来实现备份 ， 不过 ， 同样存在上面说的资源浪费问题 。
可扩展性
庞大的单体服务如果出现性能瓶颈只能对软件整体进行扩展 ， 可能真正影响性能的只是其中一个很小的模块 ， 我们也不得不付出升级整个应用的代价 。 这在微服务架构中得到了改善 ， 你可以只对那些影响性能的服务做扩展升级 ， 这样对症下药的效果是很好的 。
简化部署
如果你的服务是一个超大的单体服务 ， 有几百万行代码 ， 即使修改了几行代码也要重新编译整个应用 ， 这显然是非常繁琐的 ， 而且软件变更带来的不确定性非常高 ， 软件部署的影响也非常大 。 在微服务架构中 ， 各个服务的部署是独立的 ， 如果真出了问题也只是影响单个服务 ， 可以快速回滚版本解决 。
易优化
微服务架构中单个服务的代码量不会很大 ， 这样当你需要重构或者优化这部分服务的时候 ， 就会容易很多 ， 毕竟 ， 代码量越少意味着代码改动带来的影响越可控 。
微服务缺点
我们上面一直在强调微服务的好处 ， 但是 ， 微服务架构不是万能的 ， 并不能解决所有问题 ， 其实这也是微服务把单体应用拆分成很多小的分布式服务导致的 ， 所谓人多手杂 ， 服务多起来管理的不好各种问题就来了 。
为了解决微服务的缺点 ， 前辈们提出了下面这些概念 。
服务注册与发现
微服务之间相互调用完成整体业务功能 ， 如何在众多微服务中找到正确的目标服务地址 ， 这就是所谓「服务发现」功能 。
常用的做法是服务提供方启动的时候把自己的地址上报给「服务注册中心」 ， 这就是「服务注册」 。 服务调用方「订阅」服务变更「通知」 ， 动态的接收服务注册中心推送的服务地址列表 ， 以后想找哪个服务直接发给他就可以 。
小小天看世界■一文带你彻底搞懂面试问的微服务、RPC、服务治理、下一代微服务
文章图片
服务监控单体程序的监控运维还好说 ， 大型微服务架构的服务运维是一大挑战 。 服务运维人员需要实时的掌握服务运行中的各种状态 ， 最好有个控制面板能看到服务的内存使用率、调用次数、健康状况等信息 。
这就需要我们有一套完备的服务监控体系 ， 包括拓扑关系、监控（Metrics）、日志监控（Logging）、调用追踪（Trace）、告警通知、健康检查等 ， 防患于未然 。
服务容错
任何服务都不能保证100%不出问题 ， 生产环境复杂多变 ， 服务运行过程中不可避免的发生各种故障（宕机、过载等等） ， 工程师能够做的是在故障发生时尽可能降低影响范围、尽快恢复正常服务 。
程序员为此避免被祭天 ， 需要引入「熔断、隔离、限流和降级、超时机制」等「服务容错」机制来保证服务持续可用性 。


推荐阅读


上一篇：冰紅茶58005650▲教你三招辨别iPhone手机真假

下一篇：#网信北京#智能测温落地600余家北京商超，AI站岗成“标配”