转载

如何利用Spring Cloud构建起自我修复型分布式系统

利用Netflix所打造的组件及各类大家熟知的工具，我们完全可以顺利应对由微服务以及分布式计算所带来的技术挑战。

在过去一年当中，微服务已经成为软件架构领域一个炙手可热的新名词，而且我们也能轻松举出由其带来的诸多比较优势。然而，我们必须清醒意识到的是，一旦开始遵循微服务思路而对现有架构体系进行拆分，就意味着我们将不可避免地进入分布式系统领域。在之前的文章中我们曾经探讨过分布式计算的八大认识误区*，由此可见此类系统本身充满着风险，而且一旦犯下这八种错误中的任何一种、我们都将面对灾难性的后果。

在我个人看来，如果要将这些误区总结成一句观点，那就是：对于一套分布式系统来说，任何关于一致性或者可靠性的表达都毫无保障可言。我们需要假定系统当中的各种行为以及组件位置始终处于不断变化状态。由此产生的后果主要有两点：组件有时候会导致糟糕的服务质量甚至令服务直接离线，我们则只能将其统称为“故障”、而很难具体阐明到底是哪里出了问题。一旦没能得到妥善处理，此类故障将引中断与停机，这意味着系统将无法按照既定设计方案为用户提供服务项目。

有鉴于此，为了享受微服务所带来的诸多优势(包括松散耦合、自治服务、分散化治理以及易于持续交付等等)，我们必须避免由单一故障依次递进而最终导致系统崩溃的恐怖状况。关于这一点，Erlang语言之父Joe Armstrong曾经在题为《如何构建永远运行、自我修复且可扩展的系统》一文中作出过透彻的表述。在他看来，此类系统看起来与我们所说的微服务架构非常相近，但其着重强调的是其作为自我修复系统的容错能力。那么对我们来说，如何才能建立起这样一套坚实可靠的系统方案?

Netflix公司在微服务架构的实施与推动方面一直扮演着先行者的角色。作为其业务构建的原则性方针之一，Netflix公司认为系统方案必须要能够承受任意组件的突发性故障，而整体系统仍能继续正常运转(这意味着我们仍然能够在该平台上观看电影，而Netflix也可以继续记录用户的观看喜好)。在尝试建立这样一套系统时，我们遭遇到以下这些常见的技术挑战：

由于需要将系统拆分成多个分布式进程，我们要如何在保证一致性与可靠性的前提下将这些配置分发至这些进程当中?
当这些配置方案需要加以修改时，我们该如何在无需重新部署全部进程的前提下对配置内容进行更新?
在这样一套系统当中，特别是对于部署于云环境内的系统，各个进程不仅内容经常变动、所在位置亦会不断转换(特别是在进行故障转移的情况下)。我们要如何准确判断那些需要进行协同的进程的具体位置?
一旦我们检测到了当前进程关联性的几种可能位置，我们该如何选择接下来要进行通信的进程实例?
假设在选定一个进程实例并与该实例进行通信的过程当中该实例出现了故障，我们该如何防止由此引发的连锁故障?
在系统综合运作行为不断给自治服务带来演进拓扑结构的情况下，我们要如何对其状态保持可视化监控、从而作出有针对性的准确调整?

事实上，大家可以部署多种样板模式及开源工具来解决上述技术挑战。Netflix公司就构建出多种组件且加以开源，并在生产环境中进行了一系列测试。从理论角度讲，我们能够利用这些工具来建立起有能力“永远运行、自我修复且实现规模化扩展”的系统。对刚刚着手建立分布式系统的朋友们来说，我们目前的第一要务在于理解这些实现模式、掌握Netflix组件并加以应用，而后将这些组件部署、管理并集成至自己的系统当中。由于采取任何新的技术依赖关系都会给软件工程方案带来前所未见的复杂性元素，因此我们建议大家最好直接采用Netflix的堆栈来尽可能减少此类潜在摩擦。

Spring工程技术团队从建立之初至今一直在努力打造出足以应对Java复杂性的强大武器。我们的早期关注重点在于消除J2EE给企业级应用程序开发者带来的生产效率影响。而着眼于最近一段时间，我们的主要精力则转移到了实现云-本地应用程序构建身上，而且这方面的大部分工作成果都被纳入或者围绕着Spring Cloud项目所展开。

Spring Cloud项目的既定目标在于为Spring开发人员提供一整套易于使用的工具集，从而保证其轻松构建起自己需要的分布式系统方案。为了实现这一目标，Spring Cloud以Netflix OSS堆栈为基础将大量实现堆栈加以整合并打包。这些堆栈而后可以通过大家所熟知的各类基于注释的配置工具、Java配置工具以及基于模板的编程工具实现交付。下面就让我们一起了解Spring Cloud当中的几类常见组件。

Spring Cloud Config Server

Spring Cloud Config Server能够提供一项具备横向扩展能力的集中式配置服务。它所使用的数据被保存在一套可插拔库层当中，后者目前能够支持本地存储、Git以及Subversion。通过利用一套版本控制系统作为配置存储方案，开发人员能够轻松实现版本与审计配置的内容调整。

如何利用Spring Cloud构建起自我修复型分布式系统

图一：Spring Cloud Config Server

配置内容会以Java属性或者YAML文件的形式体现。该Config Server会将这些文件合并为环境对象，其中包含易于理解的Spring属性模型以及作为REST API存在的配置文件。任何应用程序都能够直接调用该REST API当中所包含的配置数据，但我们也可以将智能客户端绑定方案添加到Spring Boot应用程序当中，并由后者自动将接收自Config Server的配置信息分配至任意本地配置当中。

Spring Cloud Bus

Spring Cloud Config Server是一套强大的配置分发机制，能够在保障一致性的前提下将配置内容分发到多个应用程序实例当中。然而根据其设计思路的限定，我们目前只能在应用程序启动时对其配置进行更新。在向Git中的某一属性发送新值时，我们需要以手动方式重启每个应用程序进程，从而保证该值被切实纳入应用当中。很明显，大家需要能够在无需重启的前提下完成对应用程序配置内容的更新工作。

如何利用Spring Cloud构建起自我修复型分布式系统

图二: 配备Spring Cloud Bus的Spring Cloud Config Server

Spring Cloud Bus的任务正是为应用程序实例添加一套管理背板。它目前依靠将一套客户端绑定至一组AMQP交换与队列当中来实现，但这一后端在设计上也实现了可插拔特性。Spring Cloud Bus为我们的应用程序带来了更多管理端点。在图二中，我们可以看到一个面向greeting属性的值被发送至Git当中，而后一条请求被发送至应用A中的/bus/refresh端点。该请求会触发以下三个事件：

应用A从Config Server处请求获取最新版本的配置内容。任意注明了@RefreshScope的Spring Bean都会被重新初始化并载入新的配置内容。
应用A向AMQP交换机制发送一条消息，表明其已经收到更新指示。
通过监听AMQP队列而被纳入Cloud Bus的应用B与应用C会获取到上述消息，并以与应用A同样的方式实现配置更新。

现在我们已经有能力在无需重启的情况下对应用程序配置进行更新了。

正文到此结束