微服务是一个很热门的话题，现在已经有数百个各种形式的会议，网络研讨会、流媒体和网络文章到处是。因此，你会以为每个人都已经意识到微服务提供的好处以及风险。然而，许多公司在没有事先准备的情况下一下跳入微服务这一趋势。实际上导致了很多失败。

一个智者曾经说过，“在业务中使用的任何技术的第一条规则是自动化适用放大现有效率。第二，自动化应用于低效运营将会放大效率低下“。这一理念也适用于微服务。下面阐述实现微服务架构的五个步骤。

1. 从绘图开始

许多开发人员在开发某个微服务时，会错误地直接编码。这可能是您最大的错误。是的，也许你会成功地服务一下; 然而，随着人数的增加，整个事情将会变得很大。

像需要创建其他产品一样，该过程必须从设计开始。通过设计，我的意思是与团队围绕桌子聚会，并在纸上（或白板）上绘制服务。首先确定您正在构建的应用程序的主要功能。然后，通过自上而下的方法，将其分解成最小的单位。最后，介绍所有这些不同部分的互连性。这些将成为您的微服务的功能。

例如，在书籍评论系统中，主要功能是比较不同的书籍。然而，必须开发许多其他功能，例如创建用户配置文件，评级，评论，书籍数据库等。确定每个功能对于将它们捕获到微服务中都是至关重要的。

这个过程将持续超过一天时间，需要很多次迭代才能完成。当然，您需要来自不同部门的许多人的意见，以获得不同的观点和观点，并确保您不会错过系统的任何功能。

2.微服务不是组织单位

根据贵公司的组织结构定义微服务是很自然的。如果您正在构建一个单体monolith应用程序，这似乎是一个适当的解决方案。然而，在实现微服务架构时这可能是错误的决定。

也许它可以用于销售部门或客户服务，但是许多组织拥有单个部门（信息中心）来处理所有数据库。因此，为所有数据库创建一个微服务将导致单点故障。这是微服务的关键特征之一 - 没有单点故障！

您通过您的服务提供的一些功能可能会延伸到几个组织部门，也可能需要为单个部门构建许多微服务器。总而言之，您应该将您的架构服从于您要提供的业务功能，而不是您公司的组织结构。

3.创建适当的团队结构

切换到完全不同的架构一定会要求公司的管理和监控活动有所变化。前两个步骤的重点是设计应用程序，为您的最终用户提供正确的功能。现在是时候确保您对新架构有适当的操作支持。

您将不得不放弃旧的部门结构，并围绕某些微服务组建团队。这意味着每个团队将由具有不同技能的各种成员组成，如系统分析师，UX / UI设计师，后端和前端开发人员等。这样，团队将从头到尾负责他们的项目（微服务） - 从开发和部署到运营，监控和管理。这反过来又会增加他们创造他们自己产品的动力。

团队的规模将由公司/项目的总体规模决定; 然而，专家认为理想的规模是每队8-10人。此外，与单体架构不同，微服务架构可让您在扩展业务时扩展团队。

当然，所有的团队都将积极合作直至整个项目的定稿。这导致我们从这种结构中得到的主要好处是 - 更快将最终产品交付到市场。

4.性能和可靠性是重要的，

切换到微服务架构的全部理念是创建一个比单体架构具有更高性能的最终产品，且更可靠（即具有较低的停机风险），当然也可以更快地投放市场。

将性能作为设计过程的一部分来解决这个问题很重要，以确保能够及早考虑任何潜在的问题。通常，微服务设计主要集中在功能问题。但是，如果在第一次遭受较大的负载时崩溃或显著减慢，则该服务将变得无用。每个服务应该有两个或三个备选机制，它们可以在其他服务内部潜在资源出现故障时继续运行，如果在可接受的时间范围内没有响应，它应该快速循环。

提前考虑让您的服务能够准备应付更大负载变化是有好处的，有助于您的应用程序迎接真正的挑战，让您在市场上具有竞争优势，这是您决定首先转向微服务的主要原因！

5.计划会变更

忽略应用程序的更改是不可能的。开发人员一直添加和删除功能; 他们改变代码，替换应用程序的核心元素，等等。更正确的说，微服务是不断发展的。

当您每天多次更新代码时，最好接受这种更改也许以后是家常便饭的事情，而不是偶尔为之。一旦认识到这一点，您会意识到从一开始就整合变革所必需的灵活性是很重要的。确保您的应用程序正常工作的一种方法是准备服务API，以便个体微服务可以继续彼此交互，即使它们发生变化。此外，也应该包括版本控制，以允许新旧服务接口。

另一方面，数据存储演进更具挑战性。改变数据表结构以支持新功能传统上是升级应用程序中最困难的部分，而微服务器并没有使其更容易。NoSQL数据库的新技术在添加新字段却不会中断现有结构方面表现得更加灵活。如果您期望您的数据存储技术能够不断与时俱进，则应将可演化的数据存储技术作为微服务设计工作的一部分。

总之，正确准备向微服务架构过渡是整个项目成功的关键因素。只有仔细规划，发挥创新的设计思维，以及正确的运营和管理结构，才能获得微服务提供的所有好处！