公司备案号查询网站,wordpress高亮linux,山西省住房与城乡建设厅网站,未来最吃香的十大行业20221. 微服务架构概念解析 2. 构建微服务架构#xff1a;使用 API Gateway 3. 深入微服务架构的进程间通信 4. 服务发现的可行方案以及实践案例 5. 微服务的事件驱动数据管理 6. 选择微服务部署策略 7. 将单体应用改造为微服务 首先让我们了解为何要将微服务纳入考量。 构建单体应… 1. 微服务架构概念解析 2. 构建微服务架构使用 API Gateway 3. 深入微服务架构的进程间通信 4. 服务发现的可行方案以及实践案例 5. 微服务的事件驱动数据管理 6. 选择微服务部署策略 7. 将单体应用改造为微服务 首先让我们了解为何要将微服务纳入考量。 构建单体应用 假设我们要开发一款全新的与 Uber 和 Hailo 竞争的打车软件。在前期的会议和需求整理后你要么需要手动创建一个新项目要么可以使用 Rails、Spring Boot、Play 或者 Maven 来生成。这个新应用可能采用了六边形架构模块如下图所示 应用的核心是商业逻辑它由定义服务、域对象和事件各模块来完成。各种适配器围绕核心与外部交互。适配器包括数据库访问组件、生成和 consume 信息的消息组件以及提供 API 或者 UI 访问支持的 web 模块。 尽管拥有逻辑缜密的模块化设计整个应用仍然以整体打包和部署实际格式依赖于应用的语言和框架。譬如许多 Java 应用被打包为 WAR 文件部署在 Tomcat 或者 Jetty 这样的应用服务器。有些 Java 应用本身就是包涵 JARs 的软件包。与此类似Rails 和 Node.js 应用也通过目录层级打包。 采用此种风格的应用非常普遍。由于 IDE 和其他工具擅长构建单一应用这类应用也易于部署。这类应用也非常容易测试。你可以非常轻松地进行端到端测试使用 Seleniu 测试 UI 。整体应用也便于部署只需将软件包复制到服务器。你也可以通过运行多个包和负载均衡实现扩展。在项目早期这么做非常有效。 踏入单体架构的地狱 很不幸这一简单的方法有着巨大的局限。成功的应用最终会随着时间变得巨大。在每个 sprint 阶段开发团队都会新加许多行代码。几年后原本小而简单的应用会变得臃肿。举个极端的例子我最近与一位开发者交流他正在开发一款小工具来分析他们应用包括几百万行代码中的几千个 JARs 的依赖。我相信每年都会有大量开发者不遗余力地对付这种麻烦。 一旦你的应用变得庞大、复杂你的开发团队将饱受折磨苦苦挣扎于敏捷开发和交付。一大原因就是应用已经格外复杂庞大到任何一个开发者都无法完全理解。最后修复 bug 和实施新功能也就极其困难且耗时颇多。更可怕的是这是一个向下的螺旋发展。代码库越难理解正确的修改就越难。最后你会深陷庞大的、无法估量的泥淖之中。 而这种应用的尺寸也会拖慢开发进度。应用越大启动时间越长。譬如在最近的调查中不少开发者指出启动时间长达 12 分钟。我也听说有的应用启动时间居然得 40 分钟。如果开发者不得不频繁重启应用服务器那大量时间就被浪费生产效率也饱受其害。 庞大且复杂的单体应用的另一大问题就是难以进行持续部署。现在 SaaS 应用的发展水平足以在单日内多次将修改推送到生产环境。然而要让复杂的单个应用达到此水平却极为棘手。想更新应用的单个部分必须重新部署整个应用漫长的启动时间更是雪上加霜。另外由于不能完全预见修改的影响你不得不提前进行大量人工测试。结果就是持续部署变得不可能。 如果单体应用的不同模块在资源需求方面有冲突的话那应用的扩展也很难。比如模块之一需要执行 CPU-intensive 图像处理逻辑最好部署到 AWS 的 EC2 Compute Optimized instances而另一模块需要内存数据库最好适配 EC2 Memory-optimized instances。由于这两个模块需要共同部署你不得不在在硬件选择方面做妥协。 单体应用的另一问题就是可靠性。由于所有模块都运行在同一进程中任何模块中的一个 bug比如内存泄漏都可能弄垮整个进程此外由于应用中的所有实例都是唯一这个 bug 将影响整个应用的可用性。 最后单体应用会让采用新框架和语言极其困难。举例来说你有两百万行使用 XYZ 框架的代码如果要使用 ABC 框架重写代码无论时间还是成本都将非常高昂即便新框架更好。这也就成为使用新技术的阻碍。 总结这个一开始曾经成功关键业务应用最终却变成一个臃肿的、无法理解的庞然大物。它使用老旧、陈腐、低效的技术几乎吸引不到出色的开发者。这个应用非常难于扩展也不稳定可靠。最终敏捷开发和交付几乎成为不可能。 你该何去何从 微服务——直击痛点 诸如亚马逊、eBay、Netflix 等公司已经通过采用微服务架构范式解决了上文第一部分提到的问题。不同于构建单一、庞大的应用微服务架构将应用拆分为一套小且互相关联的服务。 一个微服务一般完成某个特定的功能比如订单管理、客户管理等。每个微服务都是一个微型应用有着自己六边形架构包括商业逻辑和各种接口。有的微服务通过暴露 API 被别的微服务或者应用客户端所用有的微服务则通过网页 UI 实现。在运行时每个实例通常是一个云虚拟机或者 Docker 容器。 对于前文所述的系统一种可能的系统分解图如下 应用的每个功能区都由其自身微服务实施。此外整个网页应用被拆分为一套简单的网页应用比如我们的打车软件拆分为乘客应用和司机应用从而能够轻松地针对特定用户、设备或者用户案例进行单独部署。 每个后端服务包括一个 REST API 和由其它服务提供的服务消耗 API。例如司机管理服务使用“通知”服务器来告知司机即将的行程。UI 服务唤醒其它服务从而呈现网页。这些服务也可能用到基于信息的异步通信。内部服务通信会在本系列文章中详述。 有的 REST API 也对司机和乘客的移动应用开放。这些应用并不能直接访问后端服务器相反通信由名为 API Gateway 的中间人调解。AIP Gateway 负责负载均衡、缓存、访问控制、API 计费、监控等通过 NGINX 高效实施。本系列的后续文章将会讲解 API Gateway。 上图是 Scale Cube 的 3D 模型来自《The Art of Scalability》 一书。微服务架构范式对应 Y 轴X 轴由负载均衡器后端运行的多个应用副本组成Z 轴数据分割将需求路由到相关服务。 应用通常同时使用这三种不同类型的扩展。Y 轴扩展将应用分解为如图一https://www.nginx.com/wp-content/uploads/2015/05/Graph-031-e1431992337817.png所示的微服务。在运行时维度X 轴扩展在输出和可用性的负载均衡后运行多个实例。部分应用会使用 Z 轴扩展来对服务进行数据分割。下图展示了行程管理服务Trip Management是如何使用 Docker 部署到 AWS EC2 上的。 在运行时行程管理服务包括多个服务实例每个服务实例都是一个 Docker 容器。为了实现高可用性这些容器运行在多个云虚拟机上。在应用实例前面是 NGINX 这样的负载均衡将请求分发给全部实例。负载均衡也可以处理缓存、访问控制、 API 测量和监控等。 微服务架构范式对应用和数据库的关系影响巨大。每个服务都有自身的数据库计划而不与其它服务共享同一个数据库。一方面这个方法类似企业级数据模型。同时它也导致部分数据的重复。然而要想从微服务中获益为每个服务提供单个的数据库计划就非常必要这能保证松散耦合。下面的图表展示了示例应用的数据库架构。 每个服务都有其自己的数据库。此外单个服务可以使用符合自己需要的特定类型的数据库即多语言一致性架构。例如为了发现附近乘客驾驶员管理服务必须使用高效支持地理位置请求的数据库。 表面上看微服务架构范式与 SOA 非常类似这两种架构都包括一套服务。然而微服务架构范式被看作不包含某些功能的 SOA 。这些功能包括网络服务说明 WS-* 和 Enterprise Service Bus (ESB) 的商品化和请求包。基于微服务的应用更青睐 REST 这样简单的、轻量级的协议而不是 WS-* 。他们也极力避免在微服务中使用 ESBs 及类似功能。微服务架构范式也拒绝 SOA 的其它部分比如 canonical schema 的概念。 微服务架构的好处 微服务架构模式有很多好处。首先通过分解巨大单体应用为多个服务方法解决了复杂性问题。在功能不变的情况下应用被分解为多个可管理的分支或服务。每个服务都有一个用 RPC- 或者消息驱动 API 定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案由此单个服务很容易开发、理解和维护。 第二这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术提供 API 服务。当然许多公司试图避免混乱只提供某些技术选择。然后这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术他们可以选择现在的技术。甚至于因为服务都是相对简单即使用现在技术重写以前代码也不是很困难的事情。 第三微服务架构模式使得每个微服务独立部署开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度譬如 UI 团队可以采用 AB 测试并快速部署变化。微服务架构模式使得持续化部署成为可能。 最后微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的实利。甚至于你可以使用更适合于服务资源需求的硬件。比如你可以在 EC2 Compute Optimized instances 上部署 CPU 敏感的服务而在 EC2 memory-optimized instances 上部署内存数据库。 微服务架构的不足 Fred Brooks 在 30 年前写道 “there are no silver bullets”像任何其它科技一样微服务架构也有不足。其中一个跟他的名字类似“微服务”强调了服务大小实际上有一些开发者鼓吹建立稍微大一些的10-100 LOC服务组。尽管小服务更乐于被采用但是不要忘了微服务只是结果而不是最终目的。微服务的目的是有效的拆分应用实现敏捷开发和部署。 另外一个不足之处在于微服务应用是分布式系统由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。此外他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事但相对于单体式应用中通过语言层级的方法或者进程调用微服务下这种技术显得更复杂一些。 另外一个关于微服务的挑战来自于分区的数据库架构。同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易因为只有一个数据库。在微服务架构应用中需要更新不同服务所使用的不同的数据库。使用分布式事务并不一定是好的选择不仅仅是因为 CAP 理论还因为当前高扩展性的 NoSQL 数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法从而对开发者提出了更高的要求和挑战。 测试一个基于微服务架构的应用也是很复杂的任务。比如对于采用流行的 Spring Boot 架构的单体式 web 应用测试它的 REST API是很容易的事情。反过来同样的服务测试需要启动与它有关的所有服务至少需要这些服务的 stubs。再重申一次不能低估了采用微服务架构带来的复杂性。 另外一个挑战在于微服务架构模式应用的改变将会波及多个服务。比如假设你在完成一个案例需要修改服务A、B、C而 A 依赖 BB 依赖 C。在单体应用中你只需要改变相关模块整合变化部署就好了。对比之下微服务架构模式就需要考虑相关改变对不同服务的影响。比如你需要更新服务 C然后是 B最后才是 A。幸运的是许多改变一般只影响一个服务而需要协调多服务的改变很少。 部署一个微服务应用也很复杂一个单体应用只需要在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相比之下一个微服务应用一般由大批服务构成。根据 Adrian Cockcroft 的分享Hailo 由 160 个不同服务构成而 NetFlix 则超过 600 个服务。每个服务都有多个实例这就形成大量需要配置、部署、扩展和监控的部分。除此之外你还需要完成一个服务发现机制后续文章中发表以用来发现与它通讯服务的地址包括服务器地址和端口。传统的解决问题办法并不能解决这么复杂的问题。最终成功部署一个微服务应用需要开发者有足够的控制部署方法并高度自动化。 自动化的方法之一是使用譬如 Cloud Foundry 这样的 PaaS 服务。PaaS 能让开发者轻松部署和管理微服务让他们无需为获取并配置 IT 资源劳神。同时配置 PaaS 的系统和网络专家可以采用最佳实践和策略来简化这些问题。另外一个自动部署微服务应用的方法是开发自己的基础 PaaS 系统。通常的起步方式是 Mesos 或 Kubernetes 这样的集群管理方案配合 Docker 使用。作为一种基于软件的应用交付方法NGINX 能够方便地在微服务层面提供缓冲、权限控制、API 统计、以及监控。我们会在后续的文章中分析它如何解决这些问题。 总结 构建复杂的应用的确非常困难。单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用那真的会很糟糕。微服务架构模式可以用来构建复杂应用当然这种架构模型也有自己的缺点和挑战。 在后续的博客中我会深入探索微服务架构模式并讨论多个话题包括服务发现、服务部署选择、以及将单体应用拆分为多个服务的策略。 转载于:https://www.cnblogs.com/ZJOE80/p/5788351.html
