服务的熔断及降级是系统鲁棒性的关键之一，这与我们常听说的服务雪崩有着紧密的关系。

从单体架构与SOA转向微服务，配置中心这个服务可能会有些陌生，尤其是单体架构，几乎不存在这样的需求。

在前几节我们确定了服务的划分、通讯协议的选择及接口的设计等，那接下我们考虑这样一个问题：我们将车贷通拆分成了30个左右的服务，这些服务怎么调用呢？

在讨论事件驱动之前我们先思考上一节服务协同中用户注册例子描述的场景，其对应的用户服务伪代码如下：

服务治理这个词相信很多读者都听过，而其核心在于对服务调用的管理，这里就涉及到服务编制（Orchestration ）与协同（Choreography ，也有称编排），两者很容易混淆，中文翻译更是词不达意（如Google翻译将Service Orchestration和Service Choreography都翻译成服务编排，百度翻译Service Choreography为服务编舞），本书使用编制与协同是为更好区别两者，为明确意图下文直接使用英文单词。

确定了服务划分微服务改造算是迈出了关键的一步，接下来我们要考虑选择合适的接口协议以实现服务间的数据通信。

服务的合理划分，即服务边界的设定是微服务成功的重中之重，是所有项目实施之前必须认真思考，严肃对待的。

一般而言产品初版为业务试错版本，要求包含核心功能、快速实现，尽早交由市场检验、收集问题待后续完善。我们也遵循这个方式，初版实现只包含贷款申请的核心流程。

为了更好地让读者理解服务架构，本书会带读者完成一个真实的系统，这个系统的选择会考察两个因素：

1. 普遍性，尽量是ToC的，大家都有接触，以避免花太多篇幅介绍业务背景，当然培训机构用烂了的”XX商城“不在考虑之内
2. 与笔者实际工作有关，这样才能在适合本书主旨的同时力求项目背景及核心需求的真实性

笔者服务过三家互金公司，从零开发过一套完整的车贷管理系统，对这块有一定的经验。 因而本书都会围绕“信贷管理系统“地建设展开。各位读者不妨将自己设定为此项目组的一员，在下文中带入自己的思考。由于篇幅有限，介绍上会突出重点，读者多为服务端开发，也为切合本书主旨，笔者会聚焦服务端并与微服务架构有关的内容。为更好阐述微服务架构，本书会此系统做一定裁剪及发散。

单体架构（Monolithic Architecture）是一种将所有功能打包在一个容器中运行的设计风格，一个实例中集成了一个系统的所有功能。通过负载均衡软件/设备实现多实例调用。

在介绍了微服务架构设计、开发、测试之后我们再谈下微服务下的运维与交付。

运维的重要性不言而喻，尤其是Service Mesh形态的微服务更是把运维的地位提升了一个量级。本章我们会重点介绍下微服务运维的几个要点及交付指标设定。

上章节我们分析了微服务改造在架构设计上需要关注的几个要点，在这一章节我们会探讨微服务下开发与测试要关注的内容。

基于上述单体架构的问题及我们既定的演进方案，车贷通开始了微服务架构的改造，诚如之前提及到微服务架构的门槛相对较高，对团队整体的技术及协作能力都有一定的要求，所以本章起会重点探讨下微服务改造的各个技术和技术以外的难点以及可能的应对措施。