企业对微服务的兴趣与日俱增，但与技术行业的任何趋势一样，保持事物的正确性是很重要的。虽然微服务在今天是一个"东西"，但你不能仅仅为了这个特殊的趋势而优化。除非你是一个初创企业，否则你很可能需要支持混合过程来实现未来。一个microservices最大的优点是，您不必受单个发布周期的约束，就可以对系统的一个或多个部分进行所需的改进。你不必把所有的东西都部署在一起。如果你想改进你的一段代码或者修正一个错误，你不必等待下一个发布周期，就像你用一个单片的那样应用程序。但是微服务方法并不是解决所有软件开发和交付挑战的灵丹妙药。很多事情都会出错，除非你对所有的问题都有一个完整的理解。以下是我的四条建议，以帮助您充分利用微服务，而不会给下游带来大问题。1。在代码之前分解数据使用微服务，你可以把一个单一的应用程序看作是一组不同的服务，它们将问题的不同部分作为一个整体来解决。电子商务应用程序是一个很好的例子，它可以分解为微服务。用户需要能够登录，他们需要能够浏览你的产品目录，得到推荐，把东西放进购物车，结账，并获得他们的付款已处理。如果您计划将现有的单片应用程序迁移到microservices架构，您需要对系统以及所有服务如何相互作用有很好的了解。你要避免过早或愚蠢地选择如何将你的巨石分解成微服务关于数据库模式的决策是否要为每个服务提供单独的数据库，或者每个服务都有私有表，并且您对外键的操作都会直接影响到的开销和总成本所有权。这里我的建议是：在分解代码之前先分解数据。在你变大之前先从一个小的整体开始如果你是从一张普通的纸和一个新的应用程序开始，从一个小的整体开始。首先，弄清楚你的域是什么样的，以及存在什么样的数据关系。你在处理事务性数据还是关系型数据？答案将对您的数据结构产生重大影响。在将应用程序重构为微服务微服务，大多数从业者需要更好地自动化部署管道，从代码签入到生产，并更好地监视该环境。您可能会查看一个服务，然后看到一个实际上可能是另一个上游问题的征兆的问题。在这种情况下，您需要有自动的流程来回滚有问题的服务，或者在蓝色和绿色部署之间切换。注意服务间的通信服务虚拟化和服务间的通信是其他大问题。微服务最重要的考虑之一就是要有好的、定义良好的公共api，这样就可以很容易地发现每个微服务并与之交互。这实际上不是关于您的开发人员是否使用REST、HTTP或JSON，而是关于他们如何使用该协议来实现健壮的服务间通信。当服务间的呼叫因设计不当而延迟或中断时，事情会很快变得复杂起来接口.微服务通常倾向于部署在容器中，因为容器提供隔离，易于设置或关闭，并且只运行一个进程。它们的占用空间也比虚拟机小，因此在资源上存在着相对显著的差异利用率。但是如果在100个容器中运行100个服务，那么从操作和管理的角度来看，您将面临后果。部署变得更加复杂，监视、日志记录和修复等活动变得越来越重要。确保你有正确的技能通过将这些分解成不同的服务，微服务允许你为每一个服务选择完全不同的技术堆栈。一种服务可以是Java，另一种是提供静态内容的简单化身服务，第三种是Apache。关键是，微服务方法允许您进行选择。你可以组建更小的、独立的团队来处理单独的服务，所以你不必担心管理一个非常大的团队。每个团队都可以在一个独立的发布生命周期中工作，并且不会受到分发。运行容器和大规模的微服务也需要多学科的技能，而这些技能目前在许多组织中还不具备。在技术和文化上，为一个单一应用程序配置团队与为微服务世界配置一个团队是非常不同的，在微服务世界中，熟悉诸如DevOps和连续交付之类的实践是非常不同的关键微服务提供了一个很好的架构，但是即使你被强制要求为你所有的新应用使用微服务，你还是要处理你的旧应用程序。尤其是大型组织，不会采用单一的体系结构。它们可以有数千个应用程序，有些是遗留的，有些是大型机，有些是用Java编写的，有些是用COBOL编写的。真正的挑战是如何管理所有的产品交付，如何将代码投入生产，并弄清楚你的交付管道是什么样子。"混合一切"是企业生存的地方-现在，在未来。软件对很多人来说，送货是件很重要的事情，软件交付看起来有点像瀑布、连续交付、DevOps和微服务。您可能有一些东西在本地运行，有些在云中，有些在容器中，还有一些在专用硬件上运行。您必须从构建、测试和操作中考虑所有这些不同的技术透视图。如果你是一个大组织的一部分，你不希望有太多不同的工具，所有这些工具都服务于稍有不同的主人，做的事情也略有不同。我强烈建议您使用一个系统、一个框架和一个平台来负责所有软件管道的交付和编排。您需要一个可以查看软件管道状态的位置，以及您处于发布和部署中的位置流程。微服务是件大事。但最终，它只是工具箱中的另一个工具。六个月后，可能会有新的东西。这不是历史的终结，微服务也不会是出来。这个文章最初出现在TechBeacon上