微服务devops_在DevOps中使用微服务的6个理由

微服务devops

Netflix，亚马逊，谷歌，PayPal和Facebook具有更多共同点，而不是它们成为利基市场的绝对庞然大物。 它们都遵循微服务架构以及DevOps。

事实证明，这些数字世界的巨头是建立在微服务的基础之上的。 并且他们使用DevOps指南来确保事情成为应该（或可能需要）的方式。

DevOps原则提出了一个好主意，即软件开发周期中涉及的所有团队都应协调一致并更好地同步。 而且微服务最终成为实现该想法的更好策略之一。

让我们进一步探讨该主题，并了解微服务架构如何帮助您坚持使用DevOps手册。

1. DevOps中的微服务–较小的团队，更好的沟通

开发，生产和测试团队之间曾经存在巨大的沟通空白。 直到一个团队完成了代码之后，其他团队才开始动手，似乎没人知道故事的另一面。 DevOps的议程是通过适当的沟通来弥合这种差距，并鼓励每个人朝着共同的目标努力。

微服务不需要每个部门都有大量成员的大型团队。 微服务的相对较小的规模导致了较小的组，因此，通信更好。 每个人都认识其他人，以及团队其他成员所面临的挑战。

当杰夫·贝索斯（Jeff Bezos）提出了“ 两个比萨饼”团队的想法时，这个想法是要消除冗长而乏味的沟通机制。 较小的跨职能团队无需多加留意交流日志，但他们所有人都了解团队其他成员的需求和挑战，情况要好得多。 如果让团队感到高兴的是两个比萨饼，这不是很大的方便吗？ :)

2.使用最适合自己的工作

Netflix是实施微服务体系结构的先驱之一。 他们就如何采用它提出了一个很好的模板。 对于微服务的好处，Netflix本身就是一个令人振奋的例子，说明使用微服务可以实现的目标。

DevOps文化强调着眼于最终目的来创建产品。 用瀑布方式，每个过程只是长链中的一个环节，通常与前，后过程有很大关系。 它增加了该过程的看管者的责任，并且增加了熵。

Netflix当时的Web工程总监和云架构师Adrian Cockroft在许多会议中详细解释了Netflix实施微服务的整个过程 。 当他描述他们无需过多担心用于构建微服务的编程语言时，您几乎可以感到他的宽容。 他解释说，只要它与他们的部署机制配合良好，他们就可以接受。 他们专注于最终产品。

有了微服务架构，团队将能够使用工作所需的最佳资源。 他们可以在考虑最终产品的情况下做出大多数决定，这只会提高软件或服务的质量。

但是，您也不应被这种自由所迷惑。 如果您未采取适当的谨慎措施，使用多种语言会使事情变得越来越复杂。

3.更好的问责制

假设您公司中有数百名开发人员，而且他们全都为单个代码做出了贡献-通常在整体式体系结构中会看到这种情况。 您使代码正式上线，让我们假设它出了点问题。 你现在在做什么 头疼的第一集是要找出问题所在，然后要怪罪游戏。

您知道我们正在谈论的那种折磨，您可能已经过了一段时间。 DevOps原则建议消除这种持续的责任感。 您不想花费时间确定这是开发团队还是运营团队的错。 您宁愿将所有精力用于消除问题。

微服务架构在使团队负责方面做得很好。 您不会发现开发人员和测试人员会反复研究该问题，而是会共同努力使产品正常工作。 最后，无论软件是否正常运行，都是他们的集体责任。 您将不会费劲，因为您需要使服务正常工作并同时找到问题的中心。

4.自治权还不错

强大的力量带来更大的责任。 而且，微服务架构不会错失事物的“力量”。 毕竟，如果您不让团队像他们所希望的那样工作，就因为缺陷而抨击团​​队，这将是不公平的。

微服务为团队提供了大量权限。 他们不必每次都要做出重要决定时都向当局查询。 当遇到障碍并使事情正常进行时，团队可以轻松决定下一步。

当我们谈论DevOps下的跨职能自主团队时，其动机是带入项目所需的所有灵活性。 还有什么比创建垂直行业更好的引入自治的方法。 微服务架构允许团队在规定的时间和预算内到达目的地时，可以将船转向任何方向。 也许您还可以制定一条规则，禁止它们在国外航行。 ：P

5.帮助创建以用户为中心的产品

对康威定律的现代解释是，最终产品最终反映了组织的内部结构。 如果您想提出在各个方面都表现出色的产品，那么它应该反映在创建该软件的团队的结构中。

通过微服务架构，您可以逆向工程Conway的法则，并从建立可以证明最终用户愿望的团队开始。 招聘DevOps工程师并不一定意味着您遵循其原则。 这比什么都重要。 这种文化表明，您需要在考虑最终用户的情况下不断改进流程和产品。

通过允许您组建看似必要的团队和资源，微服务为您提供了一个良好的开端。 然后，您可以根据需要修改它们。 您可以继续进行更改而不影响整个系统的事实也很有帮助。 由于微服务相对独立于服务的其他功能，因此引入更改不会有太多困难。 持续改进的周期会一直持续下去，直到您为用户提供满意的产品为止。

6.接受自动化和测试

在DevOps的原则下，大量强调持续改进和使您能做到的一切自动化。 在微服务问世之前，测试通常是在艰苦的软件开发周期之后进行的。 就像单片架构中该过程的其他步骤一样，它曾经消耗大量时间。

微服务将应用程序堆栈分解为较小且相对独立的服务。 通常，这种较小的服务只能处理一项功能。 因此，单元测试最终变得更快，更容易自动化。

由于这些微服务，我们现在一天之内就会看到多个微版本。 过去要花几个月的时间现在要花几个星期，而现在要花几个小时的时间只需要几秒钟。 微服务的更轻松测试和自动化与它有很大关系。 这种增加的测试和发布频率的甜味副产品是更低的成本。

DevOps是一个很棒的主意，几乎每个人听起来都不错。 但是当涉及到实现时，人们经常会发现自己处在棘手的情况下。 微服务架构使坚持DevOps原理变得容易得多。

DevOps和微服务的一些重叠领域包括更好的通信，更多的自动化和更好的问责制。 对于DevOps的其他优点，例如专注于最终产品和持续改进，您可以放心，微服务是推动您朝着这个方向发展的理想催化剂。

翻译自: https://www.javacodegeeks.com/6-reasons-you-should-imply-microservices-in-devops.html

微服务devops