本书共分为18章，全面涵盖了通过Spring Cloud构建微服务的相关知识点。第1、2章详细介绍了微服务架构和Spring Cloud。第3、4章讲解了通过Spr-ing Cloud构建微服务的准备工作。第5～14章以案例为切入点，讲解了通过Spring Cloud构建微服务的基础组件，包括Eureka、Ribbon、Feign、Hystrix、Zuul、Gateway、Consul、Config、Sleuth、Admin等组件。第15～17章讲述了使用Spring Cloud OAuth2来保护微服务系统的相关知识。第18章用一个综合案例全面讲解了如何使用Spring Cloud构建微服务，可用于实际开发中。
本书既适合Spring Cloud初学者使用，也适合正在做微服务实践的架构师或将要实施微服务的团队参考，同时也可作为高等院校计算机相关专业的师生用书和培训学校的教材。
序
在业务驱动的时代，企业大多急于解决效率、成本和质量的问题，开发团队的不稳定，导致业务设计、技术架构和代码脉络的不连续性。企业领导对技术储备的不重视，导致企业内部重业务、轻技术，很多研发人员缺乏设计意识。各个行业对软件系统的诉求越来越多，导致软件系统规模不断增大、复杂度不断增加，最终的结果是系统难以扩展、维护、重构、跟踪、评估工期。软件在发展过程中会面临遗留系统的种种问题，但“外科手术”治不好遗留系统复杂的病症，这是架构需要演进的根源之一。
复杂系统的各个组成部分自然趋向于混乱无序，越混乱，越稳定。如果要打破混乱、建立秩序，根据熵增定律，就要赋予系统一定的力量或者能量。混乱是事物最自然的状态，秩序却不是，但是人们希望有秩序，所以要付出代价建立制度，并维护秩序。
在这个背景下，软件系统的架构一步步演进和发展，经历了单体架构、分布式应用架构、微服务架构、服务网格架构、Serverless架构……其中，单体架构经历了简单单体时期（例如经典的JSP）、MVC分层时期（各种MVC框架受到追捧）、前后端分离时期。从整体上看，这一次次的演进是软件垂直和水平方向上的拆分，屏蔽了底层与重新定位。在演进过程中，软件开发人员的关注点越来越远离底层的部分，更多地关注上层简单的架构，技术团队的职能划分也越来越清晰。这使得软件的研发过程更高效，质量更可控，工期也更易评估。从这个角度来看，作为技术人员，我们都需要用历史的眼光去看技术的发展，拥抱变化。
微服务架构不是银弹，就像最近不断被提起的中台不能解决所有企业的问题。我们有时会存在某种认知的误区，对成功案例方法本身的关注甚于对问题本身的关注。企业的健康发展在于发现、分析和解决自身的问题，而不是盲目模仿成功的企业。
基于以上的警示，是否要在团队内部进行微服务实践？微服务落地该如何选型呢？作为一个技术人员，选择需要慎重。希望Spring Cloud能够帮你解决当前的问题，而不只是做一个简单的门户或者网站，因为没有必要为一两个简单的管理系统来维护Spring Cloud的一整套组件。在为新系统和遗留系统选择使用Spring Cloud前，我们需要分析当前面临的问题。
我见过一些团队对选型的背景、原因和目的并不是十分了解，就在新项目中直接使用Spring Cloud，只是为了不让自己与当前服务化阶段受追捧的微服务架构潮流脱节。很少有人在选型前对自己软件系统的规模、所在企业的底层资源自动化的程度、技术团队的组织形式、当前业务所面临的问题、团队的技术栈，以及引入Spring Cloud的成本等进行关注和研究。
我也见过一些团队在遗留系统复杂度高、业务耦合严重、模块划分不清晰，甚至模块拆分在垂直和水平层面都不彻底时，整个系统臃肿不堪，团队迫不得已用Spring Cloud将遗留系统强势进行拆分，在将复杂系统迁移到Spring Cloud的过程中遇到了很多问题。