21CTO导读：切换到微服务，比软件架构更有价值，它还体现了我们如何建立软件开发的文化。

 


 
 
单体系统随着系统的不断增长，当运行能力越来越无法支持时，它的增长就会陷入停滞。
 
从单体架构向微服务架构转型是一段绝对值得付出的旅程。微服务为我们提供了灵活的可扩展性，快速部署以及适应等特性。
 
转向微服务架构需要有一个深思熟虑的规划以及诸多内外部因素的综合考量。
 
第一，制定过渡计划
 
要把大量积累或遗留的应用程序分解为微服务，肯定是件有风险的事情。如果做得出现瑕疵，系统可能会受到难以挽回的重大损失，因此需要我们慎之又慎。
 
与任何一个软件工程一样，我们要首先要制定一个以业务需求为中心的计划和路线图，这件事必不可少。
 
如果你确定要将架构升级到微服务，先停止在整体架构之上开发和构建应用程序，需要在微服务架构来引入相关新功能和子系统。这可以在处理新项目时淘汰掉旧的和不需要的功能，微服务后面将帮你清理相关的技术债务。
 
在规划微服务架构时，请记住：微服务有自己独立的生态系统，他们拥有自己的数据库和UI界面。因此，要考虑如何为每个微服务分配资源。
 
慢慢循序渐进地分解老架构
 
在您转向微服务架构的过程中，这可以在初始规划阶段完成，首先，评估您的整体架构。确定架构中的所有关键组件以及系统间的关系。
 
理想情况下，您应该将任何遗留系统转换为松散耦合的组件为目标，需要频繁更新。
 
以下是使用微服务的理论的充足理由：
 
根据《架构构建进化论》的作者Neal Ford的说法，从整体中提取组件包括提取组件的数据，逻辑和UI，然后将它们重定向到新的服务。
 
对于开发人员而言，这需要做大量地工作，而我们希望转变为微服务的组件需要证明改变后的优势。
 
首先这些组件可以最大限度地减少工程师的工作量。此外，频繁更新的组件会在成为微服务后受益，因为只需要部署为隔离的服务而不用是整个系统。
 
Vivek Juneja在The New Stack中所写的那样，过渡到微服务涉及在“最小化变化”的同时，逐步替换功能。最后你如果想要整个系统崩溃，你一定要对过渡有所了解。
 
确定每个微服务的合适尺寸
 
在向微服务过渡期间，经常出现的一个有争议的话题是，如何确定每个服务的大小。毕竟，微服务的主要目标是“不要让它成为一个整体”，Juneja也曾经这样说过。
 
微服务遵守单一责任原则，即每个微服务执行单一单边之功能，是确定微服务大小的主要驱动力。
 
还有一个问题，我们还应该记住，是否有必要为特定功能都转成微服务？答案是，如果一个函数在单体架构中运行地良好，那你为什么要打破它。
 
使用API网关
 
由于微服务独立运行，为了提供与单体系统相同的功能，它们需要相互通信集成。通过微服务重新设计系统的一部分时，常见做法是使用胶水代码。
 
使微服务相互通信的最佳选择是使用API网关。使用API网关，可通过API调用将各个微服务组合在一起、集成在一起。这样一来，我们可以显着降低集成的成本，并在必要时轻松添加和删除组件。
 
我们也可以为单体系统开发API，以使不同的微服务能够连接整体系统。
 
拥抱DevOps文化
 
在微服务架构中，通常的做法是将一个团队（或者一个工程师）分配给一个微服务。但是让两个孤立的团队处理单个微服务并不是一个好习惯。
 
这也就是DevOps的用武之地了。我们借助DevOps，分配给微服务团队中的每个成员都具有跨职能职责，这意味着他们对微服务的整个生命周期（从开发，部署，测试到发布）完全负责。
 
DevOps促进了一个协作的工作环境产生，这不应该被孤立到一个单独的微服务。你打破的大系统越多，就应该确保每个微服务团队公开沟通和相互之协作。
 
除了DevOps之外，制定一些服务治理也很重要。微服务架构的一个好处是团队可以使用他们擅长的数据库，编程语言和框架来开发微服务。然而，缺点是缺乏标准化将导致多个版本和库。因此，技术负责人需要确保设置一些规则，以指定开发团队的工具和解决方案的统一性。
 
巧用容器（首先用于测试，然后再用在其他方面）
 
在逐步过渡到微服务架构时出现的一个最大问题就是测试。在过渡期间以及开发微服务时，开发团队需要定期对单体系统进行集成测试。这是为了确保跨越预先存在的单体系统和新微服务的任何操作都不会出错。
 
如果想避免在现有的单体系统上出现问题，测试是必要的，但最好不要对现有的单体模型运行测试。实现此目的的一个好方法是用Docker和Kubernetes对整个系统进行容器化，实现容器编排。这样，你将能够部署测试软件基础架构，并为自己的团队提供在本地执行集成测试的能力，而不会再影响整个系统。
 
打破单体变成微服务？稳健是赢得比赛的关键
 
前面提到过，我们过渡到微服务架构并非一蹴而就。需要考虑的因素有很多，例如了解需要隔离的组件，所需的时间，测试，API什么时候使微服务相互通信，以及采用全新的devops文化理念和思维方式等。
 
单体架构的整体转型应绝对是一个渐进的过程，这会帮助我们减轻任何不必要的小麻烦，让系统更加稳，对不对？
 

编译：华山
作者：Gunnar Peipman