序

在业务驱动的时代，企业大多急于解决效率、成本和质量的问题，开发团队的不稳定，导致业务设计、技术架构和代码脉络的不连续性。企业领导对技术储备的不重视，导致企业内部重业务、轻技术，很多研发人员缺乏设计意识。各个行业对软件系统的诉求越来越多，导致软件系统规模不断增大、复杂度不断增加，最终的结果是系统难以扩展、维护、重构、跟踪、评估工期。软件在发展过程中会面临遗留系统的种种问题，但“外科手术”治不好遗留系统复杂的病症，这是架构需要演进的根源之一。

复杂系统的各个组成部分自然趋向于混乱无序，越混乱，越稳定。如果要打破混乱、建立秩序，根据熵增定律，就要赋予系统一定的力量或者能量。混乱是事物最自然的状态，秩序却不是，但是人们希望有秩序，所以要付出代价建立制度，并维护秩序。

在这个背景下，软件系统的架构一步步演进和发展，经历了单体架构、分布式应用架构、微服务架构、服务网格架构、Serverless架构……其中，单体架构经历了简单单体时期（例如经典的JSP）、MVC分层时期（各种MVC框架受到追捧）、前后端分离时期。从整体上看，这一次次的演进是软件垂直和水平方向上的拆分，屏蔽了底层与重新定位。在演进过程中，软件开发人员的关注点越来越远离底层的部分，更多地关注上层简单的架构，技术团队的职能划分也越来越清晰。这使得软件的研发过程更高效，质量更可控，工期也更易评估。从这个角度来看，作为技术人员，我们都需要用历史的眼光去看技术的发展，拥抱变化。

微服务架构不是银弹，就像最近不断被提起的中台不能解决所有企业的问题。我们有时会存在某种认知的误区，对成功案例方法本身的关注甚于对问题本身的关注。企业的健康发展在于发现、分析和解决自身的问题，而不是盲目模仿成功的企业。

基于以上的警示，是否要在团队内部进行微服务实践？微服务落地该如何选型呢？作为一个技术人员，选择需要慎重。希望Spring Cloud能够帮你解决当前的问题，而不只是做一个简单的门户或者网站，因为没有必要为一两个简单的管理系统来维护Spring Cloud的一整套组件。在为新系统和遗留系统选择使用Spring Cloud前，我们需要分析当前面临的问题。

我见过一些团队对选型的背景、原因和目的并不是十分了解，就在新项目中直接使用Spring Cloud，只是为了不让自己与当前服务化阶段受追捧的微服务架构潮流脱节。很少有人在选型前对自己软件系统的规模、所在企业的底层资源自动化的程度、技术团队的组织形式、当前业务所面临的问题、团队的技术栈，以及引入Spring Cloud的成本等进行关注和研究。

我也见过一些团队在遗留系统复杂度高、业务耦合严重、模块划分不清晰，甚至模块拆分在垂直和水平层面都不彻底时，整个系统臃肿不堪，团队迫不得已用Spring Cloud将遗留系统强势进行拆分，在将复杂系统迁移到Spring Cloud的过程中遇到了很多问题。

《深入理解Spring Cloud与微服务构建（第2版）》深入浅出地讲解了Spring Cloud生态组件，包括服务注册发现组件Eureka、配置中心Spring Cloud Config、容错组件Hystrix、接入赋能组件Zuul、路由负载均衡组件（高可用性和稳定性）Ribbon等，使读者能够熟悉Spring Cloud各组件的作用和使用方法。

此外，本书还对一些技术点举一反三，例如在讲解RestTemplate作为网络请求时，提到其他Spring Template，包括JdbcTemplate和JmsTemplate等。本书实用性强，代码示例全面，能够使读者在技术学习方法与认知上有一定的转变和提升。

我相信无论是正在学习Spring Cloud的朋友，还是正在推进或选型Spring Cloud落地的团队，都能从本书中有所收获。

中国的近现代史是一段“师夷长技以制夷”的历史，在如今信息技术和互联网技术快速发展的时代，我们不能只停留于学习和模仿，更要发现、耕耘、创新。在此与大家共勉！

徐凌云 高级架构师

2019年夏 于湖北