对于某些人来说，微服务是将应用程序重做和重构为相对现代的样式的能力。 由于应用程序各个部分的交互的特殊性，该体系结构解决方案不适用于其他解决方案。 在任何情况下，选择一种架构，研究从从整体到一组服务的过渡中他人的经验都是有用的。
我们要求分享我们有关微服务开发和交付的案例研究，2GIS首席工程师Alexei Baitov。 让我们谈谈架构解决方案，部署和可伸缩性。 让我们问一下流行趋势，以及方便的工作工具。
-Alexey，请向我们介绍一下您自己以及2GIS中的团队。 你现在在忙什么
我于2003年以系统管理员的身份加入IT，并于2011年投入开发。 在此期间，他从事PHP，JavaScript的工作，为Git实现了一系列RESTful服务和Python驱动程序。 自2015年以来，我一直在2GIS中工作。
他参与了两种微服务架构的开发。 第一项包括一项服务。 它是带有缓存的异步反向代理。 实际上，他从事发送消息的工作。 我是参与制定需求，开发和构建DevOps的唯一人员，但是2GIS公司的专家帮助了我。
该服务是用Go编写的。 快速编译使我不必等待，因此我能够专注于持续部署。 然后我们才刚刚开始使用
GitLab CI ，
Prometheus ，
Grafana和
Deis （
Heroku的开源类似物）。 我们有一个基础架构和运营团队，在我进行开发时，这些团队将所有这些基础架构解决方案提高到了生产就绪水平。 我决定尝试所有这些，并成功实现了独立的微服务。
两年前，我转到另一个团队从事新项目，在那里我开始在Scala中从事函数式编程。 我们的团队从头开始开发了一种微服务架构，用于在Scala，C＃和JavaScript中存储2GIS广告资料。 我使用构建DevOps实践（连续部署和维护）所获得的工具和经验为所有服务奠定了基础。 建筑已从原型发展到工业运营。 她吸收了两个整体，现在由15个服务组成，并且在不断扩展。
-您是否同意微服务本质上是一组具有共同特征的独立部署的服务，也就是说，一组特定功能使它们具有微服务的外观？ 是否需要扩展此定义？ 或者，实际上，公司对微服务架构是否有不同的理解？我喜欢以下
定义 。 微服务架构是一种架构样式，可将应用程序构造为实现特定业务逻辑的松散耦合服务的集合。 微服务架构中的服务可能不具有共同的特征，但是会在共同的业务逻辑中组合在一起。
当然，每个公司都会有自己的微服务。 这是一组实践：分布式体系结构，持续集成和交付，等等。 如果将实践的概念扩展到所使用的工具，则实现微服务的选项将非常多样化。
-对于团队的组成有不同的看法，应该在编写和支持微服务时参与其中。 您如何看待？ 开发微服务架构时，最佳团队规模是多少？如何通过内部互动来构建团队？ 您的实践中是否有很好的团队合作范例？以某种方式开发服务，使其整个主题领域都适合一位开发人员的头脑，这被认为是正确的。 同时，几个人可以参与此服务的开发。 这将有助于避免开发商休假或生病时的公交因素。 正确细分服务，可以让新用户快速进入上下文。
微服务架构告诉我们，它通常包含多个服务。 因此，一个开发人员做不到。 微服务架构建立在产品模型（或通用业务逻辑）上。 选择开发人员的目的是要实现该模型，同时将重点放在客户端上。
通过开发人员与客户之间的直接联系来组织针对客户的关注。 开发人员需要查看其产品的使用方式。 由此，希望获得技术领域的知识，将产品交付给客户并尽快陪同产品的能力。
关于团队的规模很难说。 也许每个人都已经知道亚马逊的创始人杰夫·贝索斯（Jeff Bezos）的说法，即面向服务开发团队的规模应该足够小，以便每个人都可以吃两个比萨饼。 在对哈布雷的评论中，有一个关于该主题的讨论，他们写道，一个人可能没有足够的一个披萨，因此，一个团队应该由一两个人组成。 马丁·福勒（Martin Fowler）引用有关两个披萨的声明说，这是关于大美国披萨的，此后他指定团队不应该有50个人，而应该有12个人。 我相信这一切都取决于产品型号。 但是到目前为止，福勒对“最多12个人”的澄清在我的实践中还是有帮助的。 我注意到在团队中，最好根据技术兴趣进行划分，以找到志趣相投的人。
团队中的每个人都不必完全了解工作中使用的所有技术领域，但是团队的全部知识应该统一。 例如，两个人参与了部署的初始构建，将来，很有可能，他们还将大大改善部署。 但是同时，整个团队应该对部署过程有很好的了解。 这将使她能够表达自己的意愿并做出改变。 为什么要两个人？ 因为有时一个人会陷入创造性的昏迷中。 在讨论中，真理诞生了。
我们自然以这种原则为基础，并结合了技术利益。 同时，开发人员还可以参与建立DevOps实践，并且QA工程师可以开发辅助的非生产服务（例如，加热缓存或在不同环境中搜索数据异常的服务）。
-几乎所有有关微服务的报告都以“在这里我们有个冰山，我们曾经看到过，看到过，看到过……...”这个应用程序的新部分为基础，然后我们开始将“部分”与主机分开... ”
告诉我，您是从头开始发展的支持者，还是在某些情况下值得从巨石中逐步得出结论？ 如何确定退出策略？我支持从零开始的发展。 但这仅在功能集不太复杂的情况下有效。 通常，会制作一个小的MVP整体。 有时有必要从根本上更改其内部实现几次。 这既可能是由于技术任务的变化，也可能是由于对实现的理解加深了-高级抽象出现在业务模型级别。 之后，您可以继续使用微服务架构。
但是，如果您从一开始就制定了这些抽象，并以不同的符号（UML，BPMN，IDEF）对其进行了绘制，以使流程中的所有参与者都了解他们的工作方式，那么马上就可以实现微服务架构。
我们通往微服务架构的道路并非一帆风顺。 起初有一个整体。 他处理文字广告材料。 三年半前，我们需要使用图形广告材料（图像，徽标）。 希望将使用文字广告材料时缺少的内容引入业务逻辑。
为了测试新的业务模型，我们将图形广告材料作为另一个技术堆栈上的第二个整体来实施。 经过一年半的运行，我们意识到这种方法是正确的。
在这段时间里，我们得到了很多心愿单，揭示了业务逻辑的粗糙性。
第二个整体的实现很难扩展到第一个。 因此，我们决定不立即在两个整体中进行开发，而是根据非常新的业务模型将它们合并到第三种架构的框架中。 创建了一个由七个开发人员，一名质量检查工程师和两名分析人员组成的团队。 该团队的两名开发人员先前创建并支持了第一个整体，而另一个则是第二个整体。 就是说，我们的团队已经在入口处很清楚以前的巨石的陷阱。
第一个整体是用C＃编写的。 第二个是在PHP中。 我们不想从第一个整体中丢失调试后的大量代码，同时需要多线程，安全代码和强类型。 PHP代码部分不属于这些要求。 因此，C＃仍然是基础，并在第一个整体框架中实现了其出色的工作-处理广告材料的内容-但基于另一种存储：S3兼容存储和Kafka。
为了使用全新的业务模型，这次选择了Scala和PostgreSQL数据库。 Scala满足了我们的技术要求。 另外，Scala开发人员与C＃开发人员位于同一楼层。 这减少了团队沟通的时间。 康韦的法律行之有效-公司的结构决定了申请的结构。 PHP开发人员已重新开发为Scala开发人员。 我刚刚以完整的CI / CD周期完成了在Golang上的独立微服务的工作，此后我加入了团队，还成为了Scala开发人员。
有趣的是，我提出的用于Scala业务逻辑而不是C＃的确切建议。 事实是我们没有足够的C＃开发人员。 PHP-shnik和我想为Scala再培训。 另外，我们有机会吸引了经验丰富的Scala开发人员。 另一点：如果我们用C＃实现所有内容，那么我们可以在输出端获得微服务架构或另一个整体。 分为Scala和C＃，不同的存储需求以及每个要求领域中经验丰富的开发人员的可用性-所有这些都直接指向微服务架构。 而我们仅从中受益。 一年前，用于处理图形和文本材料的微服务体系结构已投入商业运营，并一直成功运行到今天。
关于是否有可能从头创建微服务架构的问题。 一年半以前，在微服务体系结构的开发过程中，我们提出了支持产品新方向的需求-视频广告材料。 必须快速测试新的销售模型。 我们的架构还处于起步阶段。 视频材料的使用涵盖了一个新的技术领域。 我们决定不更改开发向量，而是将视频材料的MVP实施为C＃和受信任的视频托管中的独立微服务架构。 这是一次成功的经验，我们有关于此主题的
报告 。 因此，我们有两个并行的现有微服务架构。 MVP并没有发展太多，Wishlist也积累了很多，不久我们将在一个微服务架构的框架内结合所有内容-我们将获得一个广告文字，图形和视频资料的单一存储库。
-立即，有两个重要的因素表明了微服务的优势。 首先是能够将各个部分输出到云的功能，因此具有巨大的可伸缩性。 第二个是用另一种语言创建单独的服务的能力。 您还看到切换到微服务还有哪些其他优势？ 好吧，当然，我也想听听这些缺点。如果我们谈论技术组成部分，那么除了上述优点之外，优点还包括使用另一种技术的可能性。 如果他不适合我们，我们将选择另一个。 新技术绕过了旧解决方案的问题。 微服务架构还提供了稳定性和独立性：一项服务的降级不应导致整个系统的完全降级。 服务可组合性允许在其他微服务体系结构中重用服务功能。 从组织组件的角度来看，划分为服务可让您将开发划分为多个分布式团队或一个大型团队。
微服务体系结构的主要缺点：它更加复杂，其实现也更昂贵。
您还需要做好准备以支持服务合同，选择正确的远程访问协议，解决安全的服务间交互，可能的故障以及对重复事务进行重复数据删除和管理的问题。
通常，在公共领域中，您可以找到有关如何使用它的大量信息和材料。 但实际上，这完全取决于任务。 在我的实践中，优点总是比缺点更重要。
仍然值得回忆一下Sam Newman的话：服务越少，微服务架构的所有优点和缺点就越多。
-您有一些有关微服务的有趣报告。 微服务的部署和微 服务体系结构中的连续部署方法 。 在第一张幻灯片的一张幻灯片中，有部署模板，并且在报告中您说对您来说趋势方法是通过容器进行分发。 在这段时间内，什么都没有改变？ 一堆Docker + Kubernetes尚未失去其相关性吗？我们正在将越来越多的服务转移到该捆绑包中。 我认为我们已经选择了正确的方向，目前我们计划坚持下去。 如果有什么变化，我将在新的报告或采访中告诉您。
-微服务的持续部署和转移到产品的顺利程度如何？这完全取决于如何构建流程。 起初，似乎一切都很简单。 服务是独立的，分别部署。 通过不同的方式来处理合同的演化，会确保缺乏一致性。 在这里，您必须选择。 例如，您可以实现合同的版本控制或添加服务以断开合同（合同解耦）。
如果在主动开发的微服务体系结构中一次有10个或更多服务，并且每个服务都有自己的版本控制，那么就会存在版本一致性问题。 我们必须尽量避免混淆不同版本的服务的兼容性。
持续部署意味着我们可以随时将应用程序交付到任何环境。
微服务架构中的应用程序是服务的集合。 因此，在任何给定时间，我们都需要知道服务版本的稳定组合。 在其他地方，我们必须具有一组特定于不同环境的域地址和其他参数，以配置服务并将它们彼此链接。
所有这些都需要存储在某个地方，以纠正多个地方的更改（毕竟微服务是独立的），并且不要感到困惑。
连续部署意味着可以随时回滚到任何版本。 因此，可能您需要一次回滚几个服务，并且需要观察服务部署的正确反向顺序。
在我的一份报告中，我谈到了合同演变的方法，它们如何解决版本一致性的问题以及如何在包含十多个服务的微服务体系结构中构建部署过程。 连续部署可能并非没有问题，但一切都可以解决。
-连续部署微服务的最初的工具是什么？ 您建议使用哪些选项来使用微服务？持续部署是一系列管道，包括持续集成，集成测试以及向业务流程环境的服务交付。 最受欢迎的步骤排序工具是
Jenkins 2 Pipelines ，
TeamCity Build Chains ，
Bitbucket Pipelines和
GitLab CI Pipelines 。 首先，您需要自动化持续集成（CI）。 我们需要一个远程CI服务器来在此程序集上构建并运行测试。
列出的工具提供了其解决方案。 我们使用GitLab CI，而GitLab Runners充当此类服务器。 构建工件是
Docker映像。 作为集成测试的一部分，您可以使用
Gatling进行负载和电容测试，尤其是确定在协调环境（例如
Kubernetes ）中运行所需的资源（处理器和内存）。
Helm广泛用于部署，它允许您描述不同环境的微服务架构。 在我们公司中，我们不使用头盔。 我们拥有自己的部署工具，该工具是在Helm为Classic版本时创建的，并且不支持其他环境。 这两个工具具有相似的有用品质，但是实现和分配不同。 而我们自己的工具使我们可以进行改进，并使所有内容都适应我们的基础架构。
-对于希望实施微服务的中小型公司，哪种技术最合适？ 这对他们来说太昂贵了吗？我越来越多地发现，中小型公司不适合提升自己的编排环境（例如
Kubernetes ，
Docker Swarm或
Apache Mesos ）。 . (
Google Cloud Platform ,
Amazon Web Services ,
Microsoft Azure Oracle Cloud ) .
GitLab GitLab CI. . GitLab Helm . Helm . Helm , , , .
, , , open source, .
Spinnaker Heroku — , , .
— , , , . . ?, . , , .
( ) . .
. . , (package). .
( ) Docker-, Git. , . ,
. , .
, . : API. . : . , API. , API , — . , API, .
. , ; API, ; , , .
, , . , ?— - .
, API, , . . .
, , . , , . , , .
— , . 2. , ? ?. .
Mesosphere ,
OpenShift PaaS IaaS . Deis
,
Deis . open source
Heroku , Heroku Buildpack', Dockerfile' Docker-. . make Deis. .
Deis2 . Deis, Kubernetes.
Infrastructure & Operations , , Kubernetes Deis2. , , Deis2, , — Kubernetes. . Deis2 : , pod pod' namespace. Infrastructure & Operations. Kubernetes . Deis2 Kubernetes. Deis2 Kubernetes.
— , , , ? ?Helm. , . Helm .
Helm , — : , .
Helm chart' chart, , .
2 , 10 . ( backing : Postgres, Kafka, Zookeeper, Ceph). - , yaml- , IDE, . , . Python, Python . , . , . , . , , . . , , , ( ) . , , Helm, Kubernetes - , yaml.
API
API Gateway . , — .
, : . , , .
DevOps原则已经牢牢扎根于开发人员的生活中，现在该是召开大型专业会议来交流经验的时候了。加入DevOpsConf俄罗斯。
DevOpsConf Russia将于10月1日至2日在莫斯科举行，从逻辑上讲将延续RootConf系列，但该系列的名称已不再反映我们在做什么。我们将从所有开发，测试和操作过程中全面讨论DevOps。
如果DevOps在您的公司中获得发展势头，或者转型刚刚开始，但已经取得了一些成功，请与社区分享。程序委员会正在等待您的申请，直到8月15日。