遵义网站建设找工作,邮件网站怎么做的,外贸营销方案,网站建设书籍赚客吧Java生鲜电商平台-微服务架构概述 单体架构存在的问题 在传统的软件技术架构系统中#xff0c;基本上将业务功能集中在单一应用内#xff0c;或者是单一进程中。尽管现代化的软件架构理论以及设计原则已推广多年#xff0c;但实际技术衍化的速度迟缓并且变革动力不足。 其中… Java生鲜电商平台-微服务架构概述 单体架构存在的问题 在传统的软件技术架构系统中基本上将业务功能集中在单一应用内或者是单一进程中。尽管现代化的软件架构理论以及设计原则已推广多年但实际技术衍化的速度迟缓并且变革动力不足。 其中的原因存在着复杂性以及多样性我想主要的原因是没有一套整体的解决方案能够让工程师在面临稳定性风险下毅然决然地实施系统重构。当系统应用规模随着业务的迅速发展时系统的重要性愈发突出开发人员将对系统的改造尤为敏感从之前的徘徊犹豫随之变得更加保守只能延续过去的技术方案将功能不断地累积在原有的系统架构上。这样的系统好比是豆腐叠罗汉叠得越高越危险。因此当面临巨大的服务压力时系统不得不通过扩容的方式来支撑应对。俗话说“船小好调头”“头病医头脚病医脚”。臃肿的系统使得扩容变得毫无针对性牵一发而动全身。由于服务运行情况存在差异性具体哪个功能存在性能瓶颈又因服务并非孤立而存在使得评估结果存在着主观臆断性和不确定性这种相互影响和作用下使得扩容变得异常的困难扩容无法量化最终导致“水桶效应”。 当应用场景规模增大时为了提高了开发以及执行的效率并且使得更优雅或者合适的解决问题成为可能开发人员将会评估和选择更先进的技术推动演进。由于系统应用过分地集中了所有功能其功能所需依赖服务以及执行库文件也随之变得庞大当需要适配新的技术时不仅依赖冲突难存在不确定性并且难以应付进而使代码重构变得异常困难增加了适配新技术的难度。 正因为功能集中于一身让应用资源占用率变得越来越大使得持续集成、回归测试、以及分发部署变得愈发困难。比如应用部署包磁盘占变多让编译、打包、分发以及启动时间变长不确定性因素变得更大。当应用发布上线后存在功能性缺陷需要回滚时这样的试错和时间成本变得更加昂贵。 越是功能集中式的系统架构在开发工程中越依赖于与执行环境。这种执行环境承载着数据、服务以及配置如若其中那个环节出现问题开发进程不得不被迫中断而不断地诊断问题和调试环境使得快速开发变得要不可及更不要说在本地开发。由于对环境的过分依赖使得系统的稳定性变得更不确定性。其一由于服务相互依赖而服务又依赖环境开发人员对单元测试职业习惯以及依赖程度降低使得测试环节减少或者说更依赖于集成测试。其二当测试人员在部署测试环境执行集成测试时不但部署成功率不断地降低而且执行过程时间不断地增加压缩了开发时间也可能导致项目滞后。不仅提高了系统风险并且增加了心理负担。这么说来无论是快速开发和测试都变得更加艰难。 以上分析还只是停留在那些熟悉业务和技术的成员当业务快速发展时其发展速度与开发效率比不断扩大招募和发展新人是必不可少的手段。当面对如此巨大和复杂的系统应用时业务和技术所需的知识变得特别杂糅让新人有一种“独上高楼望尽天涯路”之感学习曲线陡峭。在实际的实施过程中文档完整性以及指导的系统性皆存在不足。 如何解决单体架构存在的问题 单体应用给我们带来的现实问题 扩容困难Problems in scalability 部署困难Problems in deployment发布回滚困难Problems in release rollback适配新技术困难 Problems in adopting new technologies 快速开发困难Problems in RAD测试困难Problems in testing学习困难Problems in learning实际上在解决单体应用的问题上数年前就出现了相应的解决方法比如SOA的技术路线。 SOA解决一个现实的问题那就是服务与服务之间解耦将古老的进程内服务调用通过网络协议转化成服务之间的调用。从早期发明了CORBA、RMI、COM、XML-PPC等技术不过问题也随之出现由于这些技术绑定在某种技术或者平台比如RMI属于Java 平台技术COM属于微软技术体系XMLPRC没有统一的协议标准因此对平台无关性的通讯需要的协议呼声强烈这时一些典型的技术陆续出现如WebServices以及MessageQueue。以及它们的集大成技术ESB。 其中的代表技术有WSDLWeb Service Definition Language、SOAPSimple Object Access Prototol等技术。由于这些通讯协议标准相对笨重虽然目前仍在被广泛的使用但逐步被淘汰是大势所趋。 为什么不选SOA而选微服务 面向服务架构SOA VS 微服务 类同 面向服务 Service-Oriented 松耦合Loose-Coupling自包含Self-Contained平台无关性Independent Platform差异 原子性Atomic自治性Autonomous开发运维体系DevOps轻量级Lightweight通讯协议Communication Protocol微服务是粒度小的SOA正由于SOA体系庞大不可能实现更好的原子性并且它采用了统一统治的方式例如ESB那样的大型解决方案。这样技术选型针对单一的服务无法实现自行管理无形之中增加了团队运维成本。开发人员不能很好的实施DevOps技术手段。同时SOA采用了WSDL、SOAP等重量级的通讯协议增加了开发成本以及性能损耗。在微服务中大多数服务API通过REST的方式暴露这样大大地降低了适配的成本。 微服务是趋势 让我们看看google和百度统计的结果吧 图片.png 图1Google中spring boot的搜索热度 spring boot和spring cloud是做微服务的最佳搭档。从图1上我们能够看到spring boot 2013年在全球开始流行一直到2017年2月到了100的热度。 图片.png 图2google中spring cloud的搜索热度 从图2上我们可以看到spring cloud从2012年开始热度都是比较平和在2015年6月之后也就是微服务开始兴起的时候spring cloud开始迅速增长在2017年2月达到了100的搜索热度。地图上没有中国估计是因为中国被墙掉了的原因 图3百度搜索中spring boot的搜索热度 图3是百度地图统计的结果我们可以看到spring boot在国内是2015年6月开始流行的2017年增长尤为突出。 图4百度搜索中spring cloud的搜索热度 图4我们可以看到spring cloud是从2016年6月开始在中国流行往往新技术要在中国流行都会落后硅谷一年看看一年前的硅谷就是现在的中国所以大家也就能够判断到了spring cloud在中国的发展曲线了也就是2018年2月spring cloud在中国的热度将达到顶峰。 虽然流行并不代表你需要。但是既然流行就有他流行的原因就有他优点。后面我们将回来认识下微服务。 什么是微服务 微服务是用一组小服务的方式来构建一个应用服务独立运行在不同的进程中服务之间通过轻量的通讯机制如RESTful接口来交互并且服务可以通过自动化部署方式独立部署。正因为微服务架构中服务之间是相互独立的所以不同的服务可以使用不同的语言来开发或者根据业务的需求使用不同类型的数据库。 微服务架构的优点与挑战 优势 服务简单只关注一个业务功能 传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性其服务端应用就像是一块铁板笨重且不可拆分系统中任何程序的改变都需要整个应用重新构建和部署新版本。在进行水平扩展时也只能整个系统扩展而不能针对某一个功能模块进行扩展。 而微服务架构将系统以组件化的方式分解为多个服务服务之间相对独立且松耦合单一功能的改变只需要重新构建部署相应的服务即可。 每个微服务可由不同团队开发 传统的开发模式在分工时往往以技术为单位比如UI团队、服务端团队和数据库团队这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工不同的服务可以采用不同的技术来实现一个团队中应该包含开发所需的所有技能比如用户体验、数据库、项目管理。 微服务是松散耦合的 微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能微服务架构中服务是高内聚的每个服务都会处理相应的业务所有的业务逻辑应该尽量在服务内部处理且服务间的通信尽可能的轻量化比如使用Restful的方式。 可用不同的编程语言与工具开发 传统的软件开发中经常会使用同一个技术平台来解决所有的问题而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性我们可以使用Node.js来开发一个简单的报表页面使用C来编写一个实时聊天组件。 挑战 运维开销 更多的服务也就意味着更多的运维产品团队需要保证所有的相关服务都有完善的监控等基础设施传统的架构开发者只需要保证一个应用正常运行而现在却需要保证几十甚至上百道工序高效运转这是一个艰巨的任务。 DevOps要求 使用微服务架构后开发团队需要保证一个Tomcat集群可用保证一个数据库可用这就意味着团队需要高品质的DevOps和自动化技术。而现在这样的全栈式人才很少。 隐式接口 服务和服务之间通过接口来“联系”当某一个服务更改接口格式时可能涉及到此接口的所有服务都需要做调整。 重复劳动 在很多服务中可能都会使用到同一个功能而这一功能点没有足够大到提供一个服务的程度这个时候可能不同的服务团队都会单独开发这一功能重复的业务逻辑这违背了良好的软件工程中的很多原则。 分布式系统的复杂性 微服务通过REST API或消息来将不同的服务联系起来这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等而面对如此多的微服务都需要分布式时整个产品需要有一整套完整的机制来保证各个服务可以正常运转。 事务、异步、测试面临挑战 跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案而现在看起来这些技术并没有成熟。 微服务设计原则 隔离 服务必须设计为单独相互隔离工作。当你将一个整体单片系统分解成一组服务时这些服务必须彼此解耦这样才能更加连贯和自给自足。每个服务应该能够处理其自己的故障而不会影响或破坏整个应用程序或系统。隔离和解耦特性使服务能够非常快速地从故障状态中恢复。服务的隔离特性具有以下优点容易采用连续交付更好的扩展有效的监控和可测试性。 自治性 隔离为自治性铺平了道路。 服务必须设计为自主自治的。它必须具有凝聚力能够独立地实现其职能。每个服务可以使用良好定义的APIURI独立调用。API以某种方式标识服务功能。自主服务还必须处理自己的数据。更流行的术语是多语言持久性其中每个服务都有自己的持久存储。 自主还确保弹性。自主服务具有以下优点有效的服务编排和协调更好的扩展通过良好定义的API进行通信更快速和可控的部署。 单一责任 服务必须设计为高度凝聚。单一的职责责任原则是服务只执行一个重要的功能。 单一责任与“微观”一词很好地结合。‘微’意味着小细粒度只与其责任范围内相关。单一责任功能具有以下优点服务组合无缝更好的扩展可重用性可扩展性和可维护性。 有界上下文 您的服务应该有多大或小 答案就在于所谓有界上下文设计原则。这是一个关键模式同时是领域驱动设计DDD建模方法。有界的上下文是关于微服务将提供其服务功能的上下文。它根据有关领域模型和识别离散边界并相应地设计您的微服务使其更具凝聚力和自主性。这也意味着跨边界的通信变得更有效率在一个有界上下文中的服务不需要依赖于另外一个有限上下文中的太多的事情了。 异步通信 在设计离散边界和使用其自己的有界上下文设计服务时跨边界的服务通信必须是异步的。异步通信模式自然导致服务之间的松耦合并允许更好的缩放。使用同步通信会阻止调用并等待响应。 处于阻塞状态的服务不能执行另一个任务直到接收到响应并释放底层线程为止。它导致网络拥塞并影响延迟和吞吐量。异步通信还可以带来实现良好定义的集成或通信模式的概念以实现涉及不同服务的逻辑工作流。 位置独立 根据设计微服务是在虚拟化环境或docker容器中部署。随着云计算的出现我们可以拥有大量可以利用动态缩放环境的服务实例。服务可以在跨小型或大型集群的多个节点上运行。服务本身可以根据底层计算资源的可用性或效率来重新定位。必须能够以位置独立的方式来寻址或定位服务。通常可以使用不同的查找发现模式来消费使用您的服务。服务的客户端或消费者不必烦恼部署或配置特定服务的位置。它只是使用某种逻辑或虚拟地址来定位服务。 转载于:https://www.cnblogs.com/jurendage/p/11332538.html
