产业气象站 「微服务架构」面向CTO的微服务简介:微服务对企业的利弊( 二 )


使用微服务的好处为您的软件选择基于微服务的体系结构对您的组织有很多潜在的好处 。
代码库与业务领域保持一致—您的微服务通常是围绕组织的实际业务功能/目标来组织的 , 这意味着开发人员和业务人员更容易理解技术和业务是如何联系在一起的 。 非常适合分布式团队——不同的开发人员/团队可以在不同的微服务上工作 , 而不会相互妨碍 。 对于分布式团队来说 , 这比一个整体式的团队要方便得多 。 更易于构建和维护——根据功能将代码库拆分为更小的独立片段意味着它们更易于理解和维护 。 Docker等许多工具简化了新微服务的创建 。 易于部署–因为您不会中断整个应用程序 , 所以您可以经常修改和部署新的和现有的微服务 。 还有一些工具可以让它变得更简单 , 比如Kubernetes 。 提高生产力——从事特定微服务的开发人员不需要等待其他开发人员完成他们的工作 。 接管自己的工作也更容易 , 因为较小的代码库更容易理解 。 质量保证也在这个过程中得到了突破 。 选择技术的自由度——每个微服务都可以用不同的技术开发 , 这样就可以为每个问题选择最有效的解决方案 。 这也在很大程度上消除了技术和供应商的锁定——你的应用程序并不完全依赖于任何第三方软件 。 高性能、高效率和可扩展性–您可以单独扩展每个微服务 。 这意味着单个服务可以部署在多个服务器中 , 以服务于增加的流量 , 而其他服务同时只消耗标准数量的资源 。 您可以以经济高效的方式保持高性能 。 可靠性—故障隔离意味着单个服务的故障不太可能影响其他服务的性能 。 在一个巨石应用程序中 , 类似的错误可能会导致整个系统崩溃 。 微服务:不同场景下的利弊到目前为止 , 您可能已经对微服务能够很好地配合的项目有了一个很好的想法 。 总而言之:
由于微服务提供了出色的可伸缩性并鼓励基于敏捷的工作流 , 因此它们非常适合于在这些领域有高要求的应用程序 。 由于代码库可以根据功能划分为完全独立开发的单元 , 因此对于分布式团队来说 , 这是一个明显的选择 , 特别是对于代表各种技术堆栈的开发人员 。 项目越复杂、流量密集、面向长期 , 就越适合基于微服务的架构 。现在 , 让我们来看看微服务什么时候不是最好的选择——微服务的缺点 。 让我们考虑几个场景 。
对Netflix有利的事情可能对我们不利大型公司 , 如Netflix , 在各地都有不同的开发团队 , 可以从微服务的模块化特性中获益匪浅 。 实现基于微服务的体系结构的成本往往比构建一个单一的应用程序要高(您需要考虑日志监视系统、请求跟踪和部署整个系统以及任何单个微服务的能力) 。 对于那些不希望出现大流量、可伸缩性问题和混合各种技术的系统来说 , 这可能不值得 。
太过敏捷会让你变得僵硬多亏了微服务 , 您可以通过单独部署每个微服务来更轻松地进行迭代 。 测试和部署成为日常工作流程的重要组成部分 , 而不是很少发生 。 但随之而来的是巨大的责任 。 随着动态变化的微服务数量的增加 , 需要大量的DevOps功能和丰富的经验才能掌握它们 。
你在创建一个新的(绿地)项目吗?你是否有一个想法 , 并想创造一个最有价值球员?你最好的选择可能是一块巨石 。 你不仅不知道你需要什么样的微服务 , 而且从一开始就不需要微服务的复杂性 。 毕竟 , 如果有必要的话 , 将来您总是可以从一个整体式架构转向基于微服务的架构 。
如何开始使用微服务?有几件事你应该记住 。 首先 , 让我们考虑一下在任何情况下都成立的观点
从头开始不要急于求成-确保项目证明了微服务的合理性 。 根据我们上面所做的所有考虑 , 确保您的项目适合微服务 。 不要仅仅从理论上讲敏捷 。 如果没有强大的敏捷文化 , 您将无法从微服务中获益 。 投资于您的DevOps文化/能力 。 DevOps也是如此——你的架构越大 , 你需要管理的微服务越多 , 它就越明显 。 【产业气象站 「微服务架构」面向CTO的微服务简介:微服务对企业的利弊】现在 , 谈谈更具体的问题(很有可能!)从单一体系结构到微服务的场景 。


推荐阅读