鄠邑建站 网站建设,南充网站建设天赐,开发app需要什么技术人才,广州注册公司代理公司在最近的Microservices Practitioner Summit峰会上#xff0c;来自Facebook的工程师Ben Christensen就目前正在普遍快速增长的分布式系统与二进制依赖关系的一种反面模式发表了自己的看法。\\Christensen谈到说#xff0c;共享类库是整个服务运行过程中最需要的部分#xff…在最近的Microservices Practitioner Summit峰会上来自Facebook的工程师Ben Christensen就目前正在普遍快速增长的分布式系统与二进制依赖关系的一种反面模式发表了自己的看法。\\Christensen谈到说共享类库是整个服务运行过程中最需要的部分另一方面这些类库总的来说也可以被认为是“一种平台”。包括像Spring、Guava和那些通常被用在路由消息和日志记录里的类库。在最后一个系统的性能优劣取决于是否具备100类库的组合。如果一个服务不能和系统进行互动的话只能说明这些类库的可用性有问题Christensen称这种情况为分布式单体架构。本质上来讲你所做的那些将成本花在分布式系统上的事情其实只是在网络上推广单体架构但是并没有从微服务架构里面获得任何好处。至于丢失的这些好处就包括多语言特点也就意味着你所开发的这个服务错过了利用最好的技术来解决特殊问题的可能性包含组织上和技术解藕方面的问题。解决处理了这些问题有助于团队进行技术升级而不需要在第一时间去获得授权。\\\\不妨在这里简单介绍一下单体架构应用Monolith网上对微服务进行介绍的文章常常以单体架构开始。这里也不例外只有在知道了单体架构的不便之后才能更容易地理解微服务架构模式所具备的各种优点。\\开发出来的服务应该是什么样子呢通常情况下这个服务所对应的代码是由多个项目所组成各个项目会根据自身所提供功能的不同具有一个明确的边界。在编译时这些项目会被打包成为一个个JAR包并最终合并在一起形成一个WAR包。接下来开发者需要将该WAR包上传到Web容器中进行解压并重新启动服务器。在执行完这一系列操作之后对服务的编译及部署流程也就完成了。如果按照单体架构组织的代码来运行的话会生成一个包含了所有功能的WAR包因此在对服务的容量进行扩展的时候我们只能选择重复部署这些WAR包来扩展服务能力而不是仅仅扩展系统瓶颈的组成。\\\\但是这种扩展方式极大地浪费了资源。比如上图在一个服务中某个组成的负载已经达到了90%也就是到了不得不对服务能力进行扩容的时候了。而同一服务的其它三个组成的负载还没有到其处理能力的20%。由于单体架构服务中的各个组成是打包在同一个WAR包中的因此通过添加一个额外的服务实例可以将需要扩容的负载降低到45%但是也使得其它各组成的利用率更为低下。可以说所有的不便都是由于单体架构服务中一个WAR包包含了该服务的所有功能所导致的。而解决该问题的方法就是微服务架构模式。\\Don’t Repeat Yourself的字母缩写DRY对很多人来说都不陌生意即不要重复造轮子。在共享代码的业务逻辑中孤立的去部署变化条件的方式正在被摒弃因为这种做法会直接影响服务执行代码的效果。Christensen强调共享代码在服务边界里面是相当完美的可是一旦泄漏的话就会有潜在的耦合可能性。Sam Newman在他的新书《Building Microservices》里提到\\\The evils of too much coupling between services are far worse than the problems caused by code duplication。\\服务之间太多的耦合所带来的弊端远比简简单单复制代码所带来的问题还要严重很多倍。\\\Christensen认为可替代的解决方案就是采用稳定的协议隐藏所有的实现细节只将数据契约和网络协议暴露出来在不依赖服务实现的前提下用户都能够使用任何技术和编程语言这才是网络该做的事情。Christensen还指出虽然在如日志记录、分布式跟踪、路由等领域没有强制的标准化需求但还是应该启用独立的类库这样用户才有权选择是否使用这些网络服务。\\Christensen认为这样的低级错误是很容易经常性犯的因为我们都知道如何使用共享类库我们也常常在短期内进行优化来达到更高效率。他还说虽然推迟解藕的成本较高可是解决方案也是有的努力在刚开始的时候就把合适的工具用在合适的地方物尽所用才能发挥最大效果。\\在最后的问答过程中他提到使用一个大的框架无可厚非只要这个框架被当作内部一个独立的服务使用就行但如果整个系统的架构不采用这个大的框架也并无大碍因为这会避免出现长期耦合。微架构或者SOA架构真正发挥所长的地方在于根据彼此独立部署的逻辑服务这些逻辑服务可以独立于其他服务进行扩展而且能够实现独立的故障切换。\\红帽公司中间件部门工程副总裁Mark Little博士也曾说过“我在微服务架构方面担心的问题之一就是你有一个整体式单体架构应用假设你随意把它分解成多个服务到头来就会分解得过细最后会有10个、100个甚至1000个微服务。但是这些微服务又彼此高度依赖以至于如果某一个服务出现故障其余服务很有可能也会出现故障。这种情况下你将一无所获。你有999个服务就在那里干等着另一个服务恢复正常运行之后才能工作。”\\查看英文原文Microservices Ending up as a Distributed Monolith
