到目前为止，您无疑已经了解了使用微服务体系结构的优势，尤其是在新建应用程序中，以及在需要尽可能提高效率的新组织中。但是您的遗留代码和应用程序呢？你是完全重写了这个巨石，还是随着时间的推移，用新的功能，作为微服务来增加？你可以从巨石中提取一些功能，但这些功能不能很好地扩展，你需要重写。您可以选择将其作为独立服务来实现。但是，您将拥有一个混合应用程序，它会带来交付方面的挑战。当这些混合应用正在向基于微服务的更灵活的架构过渡时，你如何交付这些混合应用？这些只是组织在规划未来产品时面临的一些挑战。幸运的是，在规划基于微服务的系统时，有几种策略可以使用。但当现有的单片系统发挥作用时，问题可能会变得复杂。 做一个巨石…至少现在是这样无论你是在使用遗留系统，试图在一个巨石旁整合微服务，还是在一个新领域工作，这个过程都会变得复杂。当你在设计一个新的应用程序时，边界的决定可能会很棘手；你不想把所有的时间都花在改变服务的边界上。服务A负责做一件特定的事情，但是如果你意识到这是错误的呢？那个东西属于服务B，因为它需要访问这个只有B才接触的服务。马丁·福勒和其他几位专家建议，从一开始就让它成为一个整体。他们说，在你知道所有依赖关系在哪里之前，不要试图把所有的东西都分离成微服务。这段时间可能只持续最初几个冲刺阶段。但是，除非模式开始出现，并且您理解了您要解决的问题，否则不要在微服务架构上花费时间。当然，有一些明显的东西需要分离出来，比如身份服务，或者登录或配置文件服务。会有一些显而易见的，相当常见的东西，你可以剥离出来，然后马上开始在微服务中工作。但你要等着看事情会怎样发展。在石头上设置服务之前，先观察图案如果您以前没有解决过问题，请在开始将依赖项分解为微服务之前了解模式是如何出现的。数据往往很困难，无论你使用的是绿地应用程序还是传统应用程序的接口。无论何时处理关系数据库，都会遇到有趣的数据结构，必须解决或克服这些结构。你可能在你的整体（或你的想法，你将要写的应用程序）的事情，你想做的，或与大块数据。但是涉及到外键，有两个表，其中一个表到另一个表有一个外键。如果您希望这两个表最终由两个独立的微服务提供服务，该怎么办？突然之间，您必须将外键从一个表加载到另一个表，但是如果您没有外键所指向的对象的代码，那么您需要考虑很多问题：我在这里缓存东西吗？我能确保事务的完整性吗？这些是在处理关系数据库问题时必须解决的棘手问题。事实上，在你的问题空间中有很多事情不必是事务性的。例如，如果您在购物车应用程序中使用推荐服务，则该数据不必是事务性的。如果系统还没有处理完最近1000个搜索，而且服务没有提供特定建议的好处，那么就没有人真正注意到了。如果我的Twitter或Facebook的feed中没有来自某人的最新帖子，那么，没关系。但这与银行应用程序大不相同，我从一个帐户中扣除钱，然后把钱转到另一个帐户。那最好是一个一致的，持久的，原子性的操作。了解巨石的好处但许多问题并非如此。开始投资于微服务的公司很快就会转向诸如消息传递、键值存储等体系结构，以及促进服务之间通信和数据共享的各种东西。突然之间，这就成了一个难题。从某种意义上说，建造一个巨石阵更容易，因为你不必担心这些问题。如果加载所有数据，并且有两个服务在同一个进程中工作，那么就可以了。但是一旦它们在两个不同的进程中，在两个不同的容器中，在不同的虚拟机中，您就必须担心数据的协调。所以在选择使用微服务时，肯定有一些问题需要解决。考虑一下微服务和容器的好处使用容器的决定如何帮助解决您面临的一些架构问题？容器非常适合微服务，因为它们的作用是单一的。容器的任务是运行一个进程，并且只在一个端口上列出，尽管也有例外。但一般来说，你使用的是一个集装箱，一个服务，一个港口。容器将事情归结为微服务的本质，它们与交付模式非常匹配。容器在开发组织中迅速流行的原因之一是它们太快了。他们很快创建和删除，因为你刚刚开始一个过程。如果您不必构建已经存在的映像，也不必从存储库下载它，那么启动容器与启动流程一样快。如果我是一个服务工程师，我需要进行集成测试或分析，那么我需要其他10到30个服务，我依赖这些服务来工作，我需要部署这些服务。如果这是一个单一的应用程序，那么我必须部署整个应用程序，这是缓慢的，而且容易出错。通常，每个人共享一台服务器。但是，它是最新的吗？是的，工程师们运行持续集成（CI），在每一个新的CI构建之后，他们对它进行测试。这真的很低效，尤其是你最后打断了别人的工作。但是如果你有一个可以启动的服务集合，那么这些服务将很快启动，它们通常不会消耗很多资源，而且很快就会消失。对于开发组织来说，这是一种更有效的工作方式。更重要的是，在这个容器中，我可以交付微服务所依赖的整个工具链。我不需要阅读wiki页面就可以弄清楚12个环境变量是什么，为了成功地启动我的应用程序，微服务和容器之间非常匹配。微服务希望成为一种功能的本质，而容器只想为单个进程提供服务。他们携手共进。虽然您可以在容器内运行一个单片应用程序，但是您不会获得容器化所提供的好处。对IT运营的影响虽然许多操作团队都在使用容器，但是在老的、老的、老的组织中很少采用容器，因为工具非常不同。当您将websphereapplicationserver用于单片应用程序时，所使用的工具有很大的不同，它运行在集群上，与数据库通信，并且有一个前端Apache服务器。也许您可以使用Chef或Puppet来配置运行应用程序的虚拟机，但这些工具集与使用Kubernetes、Mesos或Amazon弹性容器功能非常不同。从操作的角度来看，你需要学习一整套新的工具。一些有趣的事情发生在基础设施供应商身上。以Docker容器为例，从Docker文件创建的图像类似于厨师或木偶配方。因此，当您停止使用一些更常见的基础设施工具而转向容器时，您将有一些选择。否则，基础设施供应商将不得不学习如何在容器生态系统中发挥作用，一些供应商已经开始朝着这个方向发展。在容器方面，您的操作团队监视微服务应用程序的能力非常重要，因为如果出现问题，每一次中断都会变成一次"寻宝"，正如我在Twitter上的一位同事最近所说。如果发生这种情况，你会问这50多个服务中哪一个是罪魁祸首。在微服务时代，监视和日志记录变得更加重要。当然，它们已经很关键了，但是如果你想在微服务架构中做得好，那就更复杂了。你必须在比赛中处于领先地位。了解企业的工作量当你在处理5000或6000个应用程序时，就像《财富》杂志20强的一些银行客户所做的那样，你无法说服企业重写所有的东西。但他们仍希望将核心技术作为新应用的一部分。这就是难题。当他们向微服务转变时，他们是否需要完全不同的技术栈来支持软件管道，这取决于他们是在做传统的单片应用程序，还是更新的微服务应用程序？或者是一种混合的方法，在这种方法中，他们有一个真正使用微服务的整体？企业有选择。即使您不想切换运行时容器服务，您也可能希望在您的计算机上本地运行，这样您在执行QA、调试和跟踪问题时有更多的控制权。容器的一个优点是它们往往是相似的。例如，如果您使用相同的Docker文件，您的容器将成为一个cookie cutter模板，可以帮助您进行生产。您拥有相同的基础设施和测试中使用的相同工具。我们想帮助我们的客户