江苏龙网

  1. 首页 > 人文 > >

关于微服务的一些误读与误解

微服务确实很受欢迎 ， 但是对于微服务的误解也是事实 ， 本文对这些误解一一来介绍下：
一、微服务不够“微”?
尽管微服务定义的很明确 ， 但是开发者社区对它的解释却颇有争议,主要的一些问题如下：
1.它是否是单体架构的代表？2.它是否是单体服务的代表？3.它是否是逻辑功能的组合？
下面让我们以银行应用为例来讨论一下：三层架构解决了技术组件之间的紧耦合问题 ， 允许它们各自独立改变而不相互依赖 。 例如：Web端的改变不会影响到后端服务 。 但是三层架构没有把基于组件分组的功能和特性考虑进去,为此我想出了一个“功能型”架构的名称 ， 以表明架构需要通过产品的特征来划分 。 这对于现代应用的性能和吞吐量是至关重要的 ， 我会在文章中对细节做进一步的解释 。
关于微服务的一些误读与误解
文章图片

二、微服务可伸缩性
【关于微服务的一些误读与误解】微服务是一种架构风格 ， 它允许你向规模化的宏伟系统进攻 ， 这是怎么做到的呢？传统的三层架构服务能伸缩可被扩展 ， 那微服务有啥特别之处呢？例如：在线旅行预定 ， 购买请求和预定请求比例是100：1
1.这意味着什么呢 ， 101个请求中 ， 购买请求能达到100个 ， 而预定请求只有1个；2.这就敲响了警钟！预定需要的资源远远小于购买所占用的资源 ， 为何不将整个系统按照期望比例缩放成100：1呢？
关于微服务的一些误读与误解
文章图片

三、微服务帮助维护和运行
“滚动式重启” ， “热部署” ， “轮询式部署 ， ”是不是听起来很熟悉？用最短的停机时间来维护应用系统 ， 是现代应用系统的一个状态优先级典型表现 。 让我们举个例子 ， 改变应用将会贯穿整个三层架构 ， 包括数据库应用程序的变化 。 如果数据的语义被修改了 ， 任何上述技术是注定要失败（（例如：ORM（对象映射关系）一旦看到了对象的变化 ， 就需要重新启动所有的节点） 。 关于微服务：功能型-层架构给高可用性和维护带来了一个新的局面 。 即使银行报表微服务奔溃了也不会影响银行系统其他的功能 。 你将会为90%的消费者不用银行报表功能感到庆幸 。
四、微服务需要进一步发掘
好吧 ， 任何关于自动伸缩的系统都需要被挖掘 。
1.在微服务中有10个节点是购物的 ， 两个节点是预定的；2.由于假日季节 ， 流入流量比较高；3.你期望通过人工分拆购物实例得到什么？4.假设分拆出了多个实例 ， 那负载平衡器又是怎么实现负责均衡的呢？
传统的负载均衡器在静态环境中能够运行良好 ， 但是当动态增加节点或执行脚本添加新实例的就很糟糕了 。 如果微服务能够实现缩放 ， 微服务项目就需要被挖掘、注册、添加实现负载均衡；对 ， 大部分的软件问题 ， 通过引用间接层来解决 。 每个微服务在关闭或启动时都需要自我注册 。 这就需要一个注册管理员-负载均衡器 ， 对微服务的加载很敏感 。 如何检查呢 ，
Netflix解决了这个问题 ， Netflix在开源EurekaAWS上实现了负载均衡 。
五、微服务是否支持多元化编程语言？
顾名思义微服务是以协议驱动的服务 ， 这些服务是基于HTTP/REST（XML/JSON数据传输）的 。 微服务与轻量级协议之间的清晰的定义边界 ， 有助于建立一个多元化的编程团队 ， 因为他们的焦点是功能而不在于选择语言 。
六、微服务和容器是天作之合？
虚拟机的笨重和现代应?程序的性质 ， 将他们分拆和拆卸为微服务 ， 使微服务成为容器的理想搭配 。 这是真正意义上的DevOps ， 打的包不仅仅是微服务的容器也是整体的一个执行环境 。 缺点是 ， 应用团队将成为基础设施团队 ， 需要对集装箱有个很好的理解 。
七、微服务添加额外的复杂性？
1.Jenkins简单通道把两个应用部署到2个Tomcats里 ， 以此类推 ， 将膨胀出无数个微服务；2.随着部署的数量增加 ， 部署的时间也跟着显著上升；3.需要有一个良好的容器管理 ， 部署和分发工具和技术；4.每个微服务将拥有更多的日志文件 ， 如果没有stash、splunk这种合适的工具 ， 对接调试事务将成为一场噩梦；5.如果每个Tomcat有10个连接 ， 你会发现数百个来自不同微服务数据库连接 ， 因为不能共享数据库连接（没有连接数据库的微服务）；
总结
所有的事情都是有代价的 ， 微服务也是一样 ， 并不是所有的应用都有同样的架构 ， 也不是所有应用对高可用性、可扩展性、可维修性都有着同样的要求 。
原文：https://my.oschina.net/vincentzhao/blog/659706


    推荐阅读


    上一篇：客土喷播技术的原理

    下一篇：俞敏洪谈瑞幸造假22亿：破坏中国企业在世界人民心中形象