快捷搜索:

如何过渡到微服务架构

当你遇到可扩展性问题或发现该问题已经变得代价高昂,并且你很难以对整体式应用程序进行定期的更新时,那么你是时候转向微服务方法了。下面来看看怎么做。

 

至此,你知道了微服务的定义和工作原理,现在是时候开始着手解决问题了:即如何实现向微服务过渡。

 

对微服务过渡的需求

 

整体式应用程序十分庞大(就代码行而言),也十分复杂(就功能相互依赖性、数据等方面而论),它为各大地理区域的数十万用户提供服务,它需要多个开发人员和IT工程师的参与。整体式应用程序可能类似于图1所呈现的样子。

 

有时,即使具备所有这些特性,应用程序一开始也许能正常运行。你可能不会遇到应用程序可扩展性或性能方面的难题。但随着时间的推移和使用的增加,问题会显现出来,而不同的应用程序会出现不同的问题。

 

例如,对于云应用程序或网络应用程序,由于有更多用户使用你的服务,你可能会遇到扩展性问题,又或者是由于耗时更长的构建时间和回归测试,云应用程序或网络应用程序可能会变得十分昂贵,而且你很难发布常规的新更新。如图2所示,整体式应用程序的用户或开发人员可能会遇到右侧列出的一个或多个问题。

 

如何过渡到微服务架构

 

如何过渡到微服务架构

 

那时,向微服务迁移就不仅仅是一个时髦的想法了,这听起来就像是救命稻草。迁移将类似于图3中所示的应用程序。

 

如何过渡到微服务架构

 

那么,你如何做出这样的改变呢?有两种可能的情况:

 

• 创建全新的应用程序。

• 转换或迁移已存在的单一应用程序。

 

后一种情况的可能性更大,但无论你目前处于什么样的情况,了解这两种情况的来龙去脉是值得的。

 

使用微服务创建新的应用程序

 

我还没有发现多少从头开始构建基于微服务的应用程序的真实场景。通常情况是,应用程序已经到位,我所研究的大多数应用程序中,从整体式架构过度到微服务架构的情况更常见。在这些例子中,架构师和开发人员的意图一直是重用一些现有的实施方案。但由于各种技能在市场上唾手可得,一些成功的实现方案已经公布,我们将看到更多从头开始构建基于微服务的应用程序的例子,因此探索这种情况当然是值得的。

 

假设你已经了解了所有要求,你已经着手设计你要构建的应用程序的架构。在你开始时,有很多常见的最佳实践可供你考虑,这些实践将在以下各节中逐一介绍。

 

组织的就绪情况

 

你必须问自己的第一个问题是,你的组织是否已准备好过渡到微服务。这意味着贵组织的各个部门现在需要以下列方式对构建和发布软件进行不同的思考:

 

• 团队结构。整体性应用程序团队(如果有这么一个团队)必须分解为几个高绩效的团队,这些团队已经了解微服务的最佳实践或接受过微服务最佳实践方面的培训。如图3所示,新系统将由一系列独立服务构成,各个独立服务负责提供特定的服务。这是微服务范式的一个关键优势:它减少了通信方面的开销,包括多个连续不断的会议。团队试图解决什么业务问题或领域,就按什么形式进行组织。于是乎,通信就关系到人们要遵循的时间和一系列标准/协议,以便这些微服务可以作为一个彼此协作的平台。

• 所有的团队都必须做好准备,独立于其他团队运作。团队必须达到标准的Scrum团队的规模;否则,沟通将再次成为问题。执行力是关键,所有的团队都必须能够满足不断变化的业务需求。

• 工具和培训。组织是否已经准备好投资新工具和人员培训,这是关键需求之一。在大多数情况下,组织必须淘汰现有的工具和流程,转而采用新的工具和流程。这将需要投入大量的资本,花钱雇用具备新技能的人并重新培训现有的员工。从长远来看,如果采用微服务的决定是正确的,那么组织将节约成本并收回投资。

 

基于服务的方法

 

与整体式应用程序不同,对于微服务,你需要采用自足的,基于服务的方法。将你的应用程序设想为一系列松散地结合在一起的服务,这些服务相互通信以提供完整的应用程序功能。每项服务都必须被视为一项独立的,完备的服务,其自身的生命周期可由独立的团队进行开发和维护。这些团队可以从各种技术中进行选择,包括最适合其服务需求的语言或数据库。

 

您可能还会对下面的文章感兴趣: