小程序wx:if过渡动画_从宏到微服务：快速过渡

小程序wx:if过渡动画

在上一篇文章中 ，我们探讨了从宏服务更改为微服务可能是一个好主意的原因。 在本篇文章中，我们了解了真实的东西：Facade代理应该如何起作用以开始替换旧服务和/或以简单的方式引入新服务，然后如何将其部署到Docker容器内的AWS上。

起初，进入新技术似乎不知所措。 当我开始研究从Docker产生的不同解决方案，库和其他项目以及诸如Kubernetes和Amazon EC2 Container Service（AWS ECS）之类的容器管理解决方案时，我就知道了。 我感到，试图对其中任何一个做出明智的选择，会使我越来越深入地研究信息，不知所措，无所适从。

因此，我将向您介绍正确的选择及其背后的推理。 在学习基础知识时，我们也将以缓慢的步伐前进，以免迷失在技术陷阱中。

使用Go作为外观代理

最初，我选择使用Node.js构建Facade代理，在使用简单的后端API方面具有一些经验。 在一个朋友反复建议我检查Go之后，我将两者进行了比较，发现Go快了好几倍，消耗了更少的资源，甚至Node.js的原始创建者Ryan Dahl也跳上了Go火车。

该语法在开始时看起来有点神秘，但在某种程度上可以识别为类似于C的语言。 潜水后，我开始掌握它了。

Go是Google开发的免费开源语言，于2009年发布，2012年达到1.0版。因此它是一种相当新鲜但仍很成熟的语言。 最新的版本（在本文撰写时）为1.8，并且可以从视频，书籍和存储库中获得许多资源，这些资源使学习起来相对容易并且（至少对我个人而言）很有趣。

您选择的语言可能不是Go，因此我不会在细节上过多介绍。 在外观代理中使用其他语言（例如C＃，Java或PHP）不会有太大的不同。 这是关于减少响应时间的开销； 这样，Go之类的语言或Node.js之类的框架就可以胜任。

我的代理应用程序在执行完整日志记录时会向请求添加一毫秒的时间，因此我认为它的速度足以达到预期的目的。

外墙代理的设计

最初，只构建一个只中继信息的代理是一个好主意。 这意味着接受请求，将其发送到实际端点，读取响应，然后将其中继到原始请求的发送者。 目前，它不需要额外的逻辑或解析其传输的数据。 直到以后才会出现。

我制作了示例应用程序以重定向每个请求，除了“ GET / healthcheck”外，该请求仅返回一个字符串。 这是因为我希望能够测试代理端点是否有效，以防实际请求无法按预期运行。 向其中添加一些实际功能很容易，例如返回N行日志或其他统计信息（例如负载，磁盘空间等）。这也使您有理由了解更多有关所选语言的信息（如果您还不是很熟悉）。

我强烈建议您还将不同级别的日志记录添加到代理中（例如，信息，调试，错误，就像在Java中一样），以便调试将来的服务更加容易。 Go提供了我认为不够的简单日志记录。 在经历了几种可能性之后，我最终对Simon Eskildsen的Logrus感到满意。 它提供了不同的日志记录级别，甚至还有很多其他的挂钩，例如，使您的应用程序可以登录到Slack。

我的应用程序使用的另一个库是Patrick Crosby的Jconfig 。 我的示例附带一个配置文件，因此您无需触摸代码即可更改API端点或本地端口。

同样，在进行生产构建时，您的部署应包含一个阶段，在该阶段中，将开发配置文件替换为生产配置文件。 将生产密码以及与代码文件保存在同一存储库中是不安全的。

运行代理

我的外观代理代码可以在https://github.com/CSTeea/facade-proxy上找到。 使用Git可以很容易地将其导入系统。 关于安装Go， https： //golang.org/doc/install上有适用于不同操作系统的指南。

安装Go并下载文件后，您可以编辑config.json文件以指向您自己的API。 我的代码示例使用上述两个库，需要运行go get github.com/Sirupsen/logrus和go get stathat.com/c/jconfig进行安装。

此后，可以使用go run facade.go启动实际的代理。 它将把端口8080定向到您定义的端点。

请注意，在我的示例中，我没有包含任何代码来重写可能的XmlHttpRequest（XHR）。 根据客户端和服务器应用程序的不同，您可能会收到错误消息，通知您请求的起点和终点不同。

将您的应用程序隔离到容器中

应用程序隔离有很多替代方法。 有些资源非常耗费资源，例如VMWare或其他虚拟机，这会使创建其他实例的过程变慢。 如果我们希望我们的微服务既轻便又快速，那绝不是一条可循的路。

另一方面，Docker不会虚拟化其主机环境，而只是在您的应用程序与下面的操作系统之间添加一层。 就部署而言，这要快得多，并且还可以使（相同映像的）不同容器共享相同的库和资源。 这使您的系统在部署更多终结点以响应不断增长的需求方面变得非常灵活和快速，并且在不需要时可以挂起它们。 所有这些都有助于使您的系统更具成本效益。 在权衡了不同的选择之后，我将Docker作为前进的道路。

由于使用Docker维护我们的运行环境是创建将来可以正常运行的微服务的关键部分，因此我的应用程序项目包含一个Dockerfile，该文件配置您的容器以安装所需的部件。 它使用安装了Go的默认Debian映像。 它还会安装所需的配置和日志记录库，定义用于暴露在容器外部的端口，并启动代理。

要在Docker容器内启动我们自己的代理，我们首先需要为其创建映像。 这是通过运行docker build -t facade-proxy . ，它基于当前目录中的Dockerfile创建一个新映像，并将其标记为“ facade-proxy”。

创建映像后（您可以通过运行docker ps -a看到它），我们可以通过运行docker run -d -p 8080:8080 facade-proxy在后台启动它。 这会将Docker容器映像作为后台作业启动，将本地端口8080重定向到容器端口8080。

请注意，如果你定义了你的API端点指向localhost配置文件中，该本地主机将现在的容器内，而不是你自己的实际本地主机点。

部署到Amazon EC2

不同的托管和云服务提供各种服务。 我的选择是Amazon，因为这是我们的API所在的位置。 因此，尽管我在这一部分中使用过AWS，但它仅适用于虚拟服务器。 由于我们还没有使用任何类型的容器管理器，因此您应该能够将此复制到您选择的提供者。

由于我的外观代理是概念验证，因此我不想花任何公司资金，而是将其部署到Amazon AMI EC2实例的免费层上。 对于简单的代理服务，这提供了足够多的资源。 因此，部署它就像启动一个新的EC2实例，访问它并安装Docker一样容易。 您不必安装Go或其他任何东西； 这些都包含在容器中。

安装Docker（并确保守护程序正在运行）之后，您可以仅在其中复制Facade代理文件（或安装Git，将它们拉出并编辑您的配置），然后再次使用docker build ...创建映像docker build ...并然后使用docker run ...启动代理。

如果您之前的步骤正常工作，那么应该也可以。 现在，您有了一个代理端点，可以从中扩展并开始为应用程序构建新功能，作为微服务（在它们自己的容器中），并在需要时将它们与宏服务分开。

下一步

我的宏到微服务系列文章中的下一篇文章将介绍将一些功能作为外部服务添加到我们的代理中，以及将其部署到容器管理服务中，您可以在其中根据需要启动服务的新实例。

翻译自: https://www.javacodegeeks.com/2017/04/macro-microservices-jumpstarting-transition.html

小程序wx:if过渡动画