江苏龙网

  1. 首页 > 人文 > >

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

单体式应用程序
与微服务相对的另一个概念是传统的「单体式应用程序」(Monolithicapplication) ， 单体式应用内部包含了所有需要的服务 。 而且各个服务功能模块有很强的耦合性 ， 也就是相互依赖彼此 ， 很难拆分和扩容 。
说在做的各位都写过单体程序 ， 大家都没意见吧？给大家举个栗子 ， 刚开始写代码你写的helloworld程序就是单体程序 ， 一个程序包含所有功能 ， 虽然helloworld功能很简单 。
单体应用程序的优点
开发简洁 ， 功能都在单个程序内部 ， 便于软件设计和开发规划 。
容易部署 ， 程序单一不存在分布式集群的复杂部署环境 ， 降低了部署难度 。
容易测试 ， 没有各种复杂的服务调用关系 ， 都是内部调用方便测试 。
单体应用程序的缺点
单体程序的缺点一开始不是特别明显 ， 项目刚开始需求少 ， 业务逻辑简单 ， 写代码一时爽 ， 一直爽 。 噩梦从业务迭代更新 ， 系统日益庞大开始 ， 前期的爽没有了 ， 取而代之的是软件维护和迭代更新的无尽痛苦 。
小小天看世界■一文带你彻底搞懂面试问的微服务、RPC、服务治理、下一代微服务
文章图片
由于单体式应用程序就像一个大型容器一样 ， 里面放置了许多服务 ， 且他们都是密不可分的 ， 这导致应用程序在扩展时必须以「应用程序」为单位 。
当里面有个业务模块负载过高时 ， 并不能够单独扩展该服务 ， 必须扩展整个应用程序（就是这么霸道） ， 这可能导致额外的资源浪费 。
此外 ， 单体式应用程序由于服务之间的紧密度、相依性过高 ， 这将导致测试、升级有所困难 ， 且开发曲线有可能会在后期大幅度地上升 ， 令开发不易 。 相较之下「微服务架构」能够解决这个问题 。
微服务微服务(Microservices)就是一些协同工作小而自治的服务 。
2014年 ， MartinFowler与JamesLewis共同提出了微服务的概念 ， 定义了微服务是由以单一应用程序构成的小服务 ， 自己拥有自己的行程与轻量化处理 ， 服务依业务功能设计 ， 以全自动的方式部署 ， 与其他服务使用HTTPAPI通信 。 同时服务会使用最小的规模的集中管理(例如Docker)能力 ， 服务可以用不同的编程语言与数据库等组件实现 。举例
还是拿前面的helloworld程序来举栗子 ， 想象一下你是helloworld公司的CTO（老板还缺人吗？会写代码的那种） ， 假设你们公司的helloworld业务遍布全球 ， 需要编写不同语种的helloworld版本 ， 分别输出英语、日语、法语、俄语...现在世界有6000多种语言（奇怪的知识又增加了） 。
有人会说这还不简单我用switchcase语句就完事了 ， 同学 ， 不要较真我就是举个例子 ， 现实中的业务比helloworld复杂多了 。 好了 ， 我们姑且认为按语言输出是个庞大复杂的工作 ， 这时候就可以用微服务架构了 ， 架构图如下：
小小天看世界■一文带你彻底搞懂面试问的微服务、RPC、服务治理、下一代微服务
文章图片
微服务与SOA「面向服务的体系结构」
SOA(Service-OrientedArchitecture)听起来和微服务很像 ， 但SOA早期均使用了总线模式 ， 这种总线模式是与某种技术栈强绑定的 ， 比如：J2EE 。 这导致很多企业的遗留系统很难对接 ， 切换时间太长 ， 成本太高 ， 新系统稳定性的收敛也需要一些时间 ， 最终SOA看起来很美 ， 但却成为了企业级奢侈品 ， 中小公司都望而生畏 。
此外 ， 实施SOA时会遇到很多问题 ， 比如通信协议（例如SOAP)的选择、第三方中间件如何选择、服务粒度如何确定等 ， 目前也存在一些关于如何划分系统的指导性原则 ， 但其中有很多都是错误的 。
SOA并没有告诉你如何划分单体应用成微服务 ， 所以在实施SOA时会遇到很多问题 。
这些问题再微服务框架中得到很好的解决 ， 你可以认为微服务架构是SOA的一种特定方法 。


推荐阅读


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

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