keras 微调整模型_如何围绕微服务调整团队

keras 微调整模型

多年来，微服务一直是整个开放源代码世界关注的焦点。尽管诸如Docker，Kubernetes，Prometheus和Swarm之类的开源技术使组织采用微服务架构比以往任何时候都更加容易，但是让您的团队在同一页面上了解微服务仍然是一个艰巨的挑战。

对于一个强调正确命名事物的行业，我们对微服务的损害很大。问题在于，微服务本质上没有“微”。有些可能很小，但是规模是相对的，并且整个组织中没有标准的度量单位。一家公司的“小型”服务可能需要一百万行代码，而另一家公司的服务要少得多。

对于一个强调正确命名事物的行业，我们对微服务的损害很大。

有些人认为微服务根本不是什么新鲜事物，而是对面向服务的体系结构（SOA）的重新命名，而另一些人则将微服务视为SOA的实现，类似于Scrum如何实现敏捷。（有关微服务定义的歧义的更多信息，请查阅即将出版的《 面向初创企业的微服务》一书。）

如果没有精确的定义，如何使您的团队在同一页面上了解微服务？在谈论微服务时，最重要的是确保您的团队扎根于一个共同的起点。模棱两可的定义无济于事。这就像试图在没有上下文的情况下将敏捷付诸实践，或是了解诸如Scrum之类的精确方法。

寻找共同点

1.能够更快地发布软件

我们的主要应用程序是一个大型代码库，有几个小型开发人员团队试图为不同目的构建功能。这意味着每次更改都必须尝试满足所有不同的群体。例如，只为一个小组服务的数据库更改必须由没有足够上下文的其他小组审查和接受。这很乏味，使我们放慢了脚步。

让不同的开发人员小组共享同一代码库，也意味着代码以故意的方式不断变得越来越复杂。随着代码库的扩大，团队中的任何人都无法拥有它，并确保所有部分的组织和最佳组合。这使部署成为一个可怕的考验。对我们的应用程序进行单行更改需要部署整个代码库，以推出更改。由于部署大型应用程序具有很高的风险，因此我们的质量保证流程有所发展，因此，我们的部署较少。

通过微服务架构，我们希望能够对代码进行划分，以便不同的开发团队可以完全拥有部分。这将使团队能够更快地进行创新，而无需繁琐的设计，审查和部署过程。我们还希望，更少的开发人员可以使用更小的代码库，这将使我们的代码库更易于开发，测试和保持组织。

2.灵活选择技术

我们的主要应用程序很大，是使用Ruby on Rails构建的，具有自定义JavaScript框架和复杂的构建过程。我们应用程序的某些部分遇到了主要的性能问题，这些问题很难解决，因此导致其余应用程序崩溃。我们看到了使用更好的方法重写应用程序这些部分的机会。我们的代码库纠缠不清，这使重写感觉非常庞大且成本很高。

同时，我们的一个前端团队希望摆脱我们的自定义JavaScript框架，并使用像React这样的更新框架来构建产品功能。但是将React混入我们现有的应用程序和复杂的前端构建过程中似乎很昂贵。

随着时间的流逝，我们的团队对于被困在太大而无法修复或替换的代码库中的感觉感到沮丧。通过希望采用微服务架构，我们希望保持单个服务的规模较小，这意味着用更好的实现替换它们的成本将更易于管理。我们还希望能够为每项工作选择合适的工具，而不是一刀切的方法。如果我们认为合适的话，我们可以灵活地在不同的应用程序中使用多种技术。如果团队想要使用Ruby以外的其他东西来提高性能，或者从我们的自定义JavaScript框架切换到React，那么他们可以这样做。

3.微服务不是免费的午餐

除了概述我们希望获得的收益外，我们还确保我们对与构建和管理微服务相关的成本和挑战持现实态度。开发，托管和管理众多服务需要大量开销（并编排了大量不同的开源工具）。在几个进程上运行的单个整体式代码库可以轻松地转换为跨多个服务的数十个进程，这需要负载平衡器，消息传递层和群集来实现弹性。管理所有这些都需要大量的技能和工具。

此外，微服务涉及分布式系统，这些系统引入了许多问题，例如网络延迟，容错，事务，不可靠的网络和异步性。

设置自己的微服务路径

一旦定义了微服务的收益和成本，我们就可以讨论架构，而不会陷入适得其反的关于谁在做对还是做错微服务的争论。我们没有尝试使用其他人的描述或微服务示例来找到自己的方式，而是专注于我们试图解决的核心问题。

拥有更多服务将如何帮助我们在未来6到12个月内更快地发布软件？
在我们的系统的一部分中使用特定的工具是否具有强大的技术优势？
我们是否预见到要用一种更合适的系统替换其中一种系统？
当我们雇用更多人时，我们如何围绕服务构建团队？
提供更多的服务是否值得在可预见的成本下提高生产率？

总而言之，在进入微服务之前，有五个建议的步骤可以使您的团队结盟：

了解微服务，同时同意没有“正确的”定义。
定义一套共同的目的和目标，以避免产生反效果的辩论。
讨论并记录您采用微服务的预期收益和成本。
避免急于跳上微服务潮流；对如何最好地构建系统的创新想法和激烈的辩论持开放态度。
牢记您的团队确定的收益和成本。

专注于确保团队有一组明确定义的共同目标可以实现。与试图确定微服务的实际含义相比，讨论和定义您希望通过微服务实现的目标更有价值。

翻译自: https://opensource.com/article/17/10/how-align-your-team-microservices

keras 微调整模型