社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
微服务是当下技术领域的热门趋势，在 Netflix、Google 和 Twitter 之类的先行者推动下，企业开始自问，采用基于微服务的体系结构是否适合他们。
在最近的另一项调查中，有36%的CIO表示，他们已经采用了微服务，另有26%受访者表示他们正处在预研阶段，鉴于微服务受接纳速度如此之快，用户可能期望对微服务的最佳实践有一份充分的了解，但是同时关于什么是微服务、以及该体系结构是否适合用户的企业仍然存在很多误解。
毕竟，对于一家初创公司来说，没有外部应用程序负担，即可轻松上手微服务；但是，对于已经拥有大量不同应用程序（不同编程语言、不同架构体系）的大型企业，每个应用程序都有各自的历史和功能，从单体应用过渡到微服务架构的过程可能会非常艰巨。
这里，我们将介绍不用的体系结构，并提供针对企业架构师的基础知识，以帮助他们进入到微服务的新世界。
十年前，Netflix、Amazon、Twitter、Google 和 eBay（仅举几例）是微服务架构趋势的早期开拓者，从那以后，微服务已成为在超增长（hyper-growth）公司构建尖端应用（cutting edge applications）程序的开发人员的首选。
正如我们所见，微服务有其优缺点，但是它们提供了以下承诺，因此能被多个行业的开发团队所广泛采用：
为了更好地了解基于微服务的开发和部署方式是否必须，让我们来看一下传统的单体应用与微服务之间的区别。
面向单体应用或微服务体系结构构建应用程序和产品，是截然不同的方式，每种方式都有其优缺点。直到最近，随着云应用程序的兴起，单体应用曾是构建应用的唯一方式。
首先，单体应用架构易于理解：没有太多的活动组件，并且通常所有内容都包含在一个代码库中。从头开始开发新应用程序时，这种方式很好，有其是在代码库和工作团队都较小的情况下。这也是开发产品并将其快速推向市场的捷径，因为不需要考虑其他依赖因素。
大多数功能是由同一个代码库提供的，该代码库通常与同一个数据库进行通信以存储对象。为了扩展单体应用，用户引入前端负载均衡器，该负载均衡器负责将流量分配到单体应用的每个副本。
在服务器端生成前端内容很常见，显而易见，这样的体系结构会对后端服务增加更多的负载，这反过来会导致其更难以扩展。此时，应用程序开始在客户端实现某些功能，这样引入了临时后端 API（ad-hoc backend APIs），这样客户端可以使用这些后端 API，以便将其中一些负载从服务器上移走。
不久之前，Ajax 和 JSON 已成为这些客户端-服务器通信的事实标准，尤其针对浏览器客户端：JSON 与 XML 不同，它容易使用 Javascript 接续，更容易构造，也更容易阅读。
随着越来越多的客户端采用这种方式，此时需要一种可以加入外部开发商或构建开发者平台的方法 ，借鉴了 Ruby on Rails 之类的框架提倡的API 优先理念，API 便成为了构建软件的公认方式。
如果代码库很小，那么可以肯定地说，选择这种体系结构带来的挑战很小，但是随着代码库的增长，问题开始显现。
单体应用是启动新应用程序，并投放到市场上进行测试的好方法，因为其中仅有几个活动组件，并且初识团队也很小，迭代过程相对较快，使用简单的蓝绿部署，开发人员即可以将改进的产品持续交付给终端用户。
但是随着代码库的增长，软件开发变的越来越困难，即使是很小的改动，也需要完全重新部署整个应用程序，如果出现问题，通常也会影响整个应用程序。
在这种情况下，曾经的优势变成了劣势：业务逻辑被捆绑在一起，并且随着代码库变的越来越大，开发人员无法正确地隔离和划分变更。
不断增长的代码库自身也面临着挑战：保持干净整洁的代码抽象，文档化的代码和良好的实践可以帮助减少技术债，但是增长的团队不断对原本良好的代码管理施加压力。新的团队成员加入团队，尝试学习并将自己的代码推向生产环境，随着时间的流逝，系统整体逐渐被破坏，管理工具也逐渐失效。新功能越来越难构建，或者一投入生产环境就报错。
这些问题的根本原因在于，随着时间的推移，很难保持大代码库的组织性和整洁度，并且在拥有不同团队成员的情况下，无法保证代码和业务逻辑的隔离，也无法保证对同一份代码，不同功能的版本控制，而最终这些都需要在生产环境中全部部署上线。
因此，不难理解，应对这些挑战的解决方案是使用较小的应用程序，但是使用单个大型应用程序。
要求也很明确，这些组件需要能够独立构建，需要独立部署，更重要的是，从事组件开发的每个团队成员不必一定要了解其他组件的细枝末节，因为任何实施细节都由负责该特定功能的特定团队来负责。
由于每个组件都忽略了其他组件的实现，因此需要一种使用接口或 API 的方法，而且由于开发人员需要能够路由和版本化请求，以独立部署和扩展请求，因此这个接口将通过网络访问，这种情况下，组件变成了服务，由于每个组件都会很好地完成一份特定的事情，因此它们倾向于变得更小，这就是为什么将它们称为微服务的原因。
如我们所见，单体应用和微服务体系结构是设计和构建软件的两种截然不同的方法，每种方法各有优缺点，在本节中，我们将总结这些优缺点。
首先先看一下单体应用，最大的好处是拥有较少的活动组件，这对于小型代码库意味着更加简单，最常见的是，应用程序运行在负载均衡器后，每次开发人员进行更改时，他们都会更新主代码库，然后重新部署整个应用程序，通过在负载均衡器后添加更多节点，来水平扩展应用程序。
团队可以有效地快速迭代和部署更新，随着团队不断迭代和改进代码库，他们可以决定每天按固定时间进行一次或多次部署，通过蓝绿部署或者金丝雀发布可以将这些更改交付给终端用户。
较少的活动组件，使得在单体应用中，可以轻松实施集成测试，因为所有内容都在同一个地方，并且团队不需要运行许多依赖项即可完全测试功能，可能数据是唯一的依赖。IDE 传统意义上是为了单体应用而构建的，例如，在 Eclipse 中，开发人员可以一键运行并测试整个应用程序。
随着应用程序变的越来越复杂时，所有这些好处很快就会消失。不断增长的代码库更难处理，尤其对于新员工，因为现在我们需要立即全局了解代码，这使学习曲线变的非常陡峭。即使对代码进行了适当的管理（具有良好的工程实践和良好的工程文化），部署大型代码库变的越来越慢，因为我们必须确保所有内容都结合在一起，并需要复查我们所做的更改是否代码库的其他区域。由于开发人员无法正确隔离实验，需要冒着影响整个应用程序的风险，因此几乎无法尝试使用新技术（例如新数据库或语言）。因为这些原因，随着应用程序体量越来越大，单体应用越来越难以创新，即使对代码库进行很小的更改，也需要完全重新部署整个应用程序。如果用户使用构建二方库的方式来分离代码库，也不能更改现状，库的每次更新仍然需要完整的部署。
另外，与此相关的是，构建和装载产品中的负面因素最终会使管理层和工程团队感到沮丧，因为发布周期越来越长，创新速度也越来越慢，任何新的更改或功能都难以实现和发布，并且呈指数级增长。团队士气和动力是开发出色产品的关键因素，并且架构选择是否对团队的工作方式和产品交付产生负面影响，是一个值得研究的危险信号。
面向微服务体系结构的真正宗旨是将业务逻辑的不同区域委派给可以单独创建、部署和扩展的单独服务。
在构建应用程序时，可以确定处理单独的业务逻辑问题的不同区域或边界，例如，在一个电子商务产品中，有订单管理、发票管理、用户管理、库存管理等功能。在面向微服务的应用程序中，架构师可能会开始将这些功能中的每个功能解耦为单独的服务，例如，更新发票生成业务仅需要重新部署应用程序的特定领域，而不会影响其他功能。
通过为每个职能部门提供不同的服务，团队现在可以自己决定何时部署和扩展自己的服务，这些服务将通过 Http/RPC API 之类的接口相互通信，而忽略实际的实现细节，只要可以从其他服务使用该接口，团队就可以使用不同的语言，利用不用的数据库来构建微服务，并在服务的上下文中使用新技术（例如新数据库、新语言和新框架）。
同时微服务还应该为新员工提供更平滑的学习曲线，顾名思义，微服务相对较小，并且专门用于执行特定的任务。最后，微服务已在体系结构中内置了隔离和可伸缩性，如果一项服务出现故障，其他服务仍应保持正常运行，而不会关闭整个应用程序。如果服务突然遇到的请求增加或减少，也可以在不影响其他服务的情况下水平扩展或缩减服务。
同样，如果一项服务遭到破坏，则可以将其隔离并脱机，而不会影响整个应用程序，也不会感染其他应用程序。
在面向微服务的架构中，大型团队消失了，转而使用了较小的披萨团队，这仅需7-8个开发人员的团队规模。每个团队现在彼此独立维护服务的构建、交付和扩展。
当然这些好处伴随着架构师需要额外的工作，微服务如同乐队一样，需要一起工作才能达到最终效果。网络需求变得更加重要，因为团队需要确保所有这些服务都已正确启动并运行，而且对比监控单个应用，监控微服务变得更加困难和复杂。随着数据在每个服务中流动，确保状态和数据的可用性和一致性也很重要，通常要考虑最终一致性的实现。虽然测试特定服务变容易，但是测试所有功能变得更加困难，因为所有这个服务都必须启动并运行。
这里，我们讨论了单体服务和微服务架构之间的差异，目的是帮助架构师了解基于微服务的架构是否适合他们的应用，我们还讨论了两个架构之间的优缺点，接下来，我们会讨论如何炸毁单体应用这颗巨石。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
