专业生产车间设计图纸网站,北京软件开发公司,成都品牌营销策划有限公司,网上挣钱正规渠道微服务确实很受欢迎#xff0c;但是对于微服务的误解也是事实#xff0c;本文对这些误解一一来介绍下#xff1a; 一、微服务不够“微”? 尽管微服务定义的很明确#xff0c;但是开发者社区对它的解释却颇有争议,主要的一些问题如下#xff1a; 1.它是否是单体架构的代表… 微服务确实很受欢迎但是对于微服务的误解也是事实本文对这些误解一一来介绍下 一、微服务不够“微”? 尽管微服务定义的很明确但是开发者社区对它的解释却颇有争议,主要的一些问题如下 1.它是否是单体架构的代表 2.它是否是单体服务的代表 3.它是否是逻辑功能的组合 下面让我们以银行应用为例来讨论一下三层架构解决了技术组件之间的紧耦合问题允许它们各自独立改变而不相互依赖。例如 Web端的改变不会影响到后端服务。 但是三层架构没有把基于组件分组的功能和特性考虑进去,为此我想出了一个“功能型”架构的名称以表明架构需要通过产品的特征来划分。这对于现代应用的性能和吞吐量是至关重要的我会在文章中对细节做进一步的解释。 二、 微服务可伸缩性 微服务是一种架构风格它允许你向规模化的宏伟系统进攻这是怎么做到的呢传统的三层架构服务能伸缩可被扩展那微服务有啥特别之处呢例如在线旅行预定购买请求和预定请求比例是1001 1.这意味着什么呢 101个请求中购买请求能达到100个而预定请求只有1个 2.这就敲响了警钟预定需要的资源远远小于购买所占用的资源为何不将整个系统按照期望比例缩放成1001呢 三、 微服务帮助维护和运行 “滚动式重启” “热部署” “轮询式部署 ”是不是听起来很熟悉用最短的停机时间来维护应用系统是现代应用系统的一个状态优先级典型表现。 让我们举个例子改变应用将会贯穿整个三层架构包括数据库应用程序的变化。如果数据的语义被修改了任何上述技术是注定要失败例如 ORM对象映射关系一旦看到了对象的变化就需要重新启动所有的节点。关于微服务功能型-层架构给高可用性和维护带来了一个新的局面。即使银行报表微服务奔溃了也不会影响银行系统其他的功能。你将会为90%的消费者不用银行报表功能感到庆幸。 四、 微服务需要进一步发掘 好吧任何关于自动伸缩的系统都需要被挖掘。 1.在微服务中有10个节点是购物的两个节点是预定的 2.由于假日季节流入流量比较高 3.你期望通过人工分拆购物实例得到什么 4.假设分拆出了多个实例那负载平衡器又是怎么实现负责均衡的呢 传统的负载均衡器在静态环境中能够运行良好但是当动态增加节点或执行脚本添加新实例的就很糟糕了。如果微服务能够实现缩放微服务项目就需要被挖掘、注册、添加实现负载均衡对大部分的软件问题通过引用间接层来解决。每个微服务在关闭或启动时都需要自我注册。这就需要一个注册管理员-负载均衡器对微服务的加载很敏感。如何检查呢 Netflix解决了这个问题 Netflix在开源Eureka AWS上实现了负载均衡。 五、 微服务是否支持多元化编程语言 顾名思义微服务是以协议驱动的服务这些服务是基于HTTP/REST XML/ JSON数据传输的。微服务与轻量级协议之间的清晰的定义边界有助于建立一个多元化的编程团队因为他们的焦点是功能而不在于选择语言。 六、 微服务和容器是天作之合 虚拟机的笨重和现代应⽤程序的性质将他们分拆和拆卸为微服务使微服务成为容器的理想搭配。这是真正意义上的DevOps打的包不仅仅是微服务的容器也是整体的一个执行环境。缺点是应用团队将成为基础设施团队需要对集装箱有个很好的理解。 七、 微服务添加额外的复杂性 1.Jenkins简单通道把两个应用部署到2个Tomcats里以此类推将膨胀出无数个微服务 2.随着部署的数量增加部署的时间也跟着显著上升 3.需要有一个良好的容器管理部署和分发工具和技术 4.每个微服务将拥有更多的日志文件如果没有stash、 splunk这种合适的工具对接调试事务将成为一场噩梦 5.如果每个Tomcat有10个连接你会发现数百个来自不同微服务数据库连接因为不能共享数据库连接没有连接数据库的微服务 总结 所有的事情都是有代价的微服务也是一样并不是所有的应用都有同样的架构也不是所有应用对高可用性、可扩展性、可维修性都有着同样的要求。 原文地址http://geek.csdn.net/news/detail/67274 .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注