本书不会重复造轮子，写出差异化，以实用性为初心，实例化引导为手段，避免阳春白雪式的理论宣导，或是皮相之谈的代码解读。总结而言本书的特点如下：
实例导向，理论为辅：笔者多年服务于互联网金融公司，本书以信贷系统这一真实项目为线索，循序渐进地介绍服务架构的来龙去脉，微服务架构的基础性理念介绍是必须的，但不会生搬硬套地解释某些知识点的设计原理，而会更加关注在架构演进过程中为什么要用到这些技术及这些技术的适用场景及局限。
言简意赅，拒绝话痨：对比国内外技术书箱，很大的差异在于国内很多作者喜欢“堆代码”，喜欢“旁征博引”，本书不求“厚”，但求“精”，对于一些显而易见或是网络中已有详尽介绍的知识点本书尽量以扩展阅读的形式呈现给读者，不占用过多篇幅介绍。
内容殷实，力求全面：在保证行文紧凑的同时，本书尽量覆盖服务架构的核心点、项目实例的全流程关键点，并且会引入一些相关的扩展话题以供探讨，IT技术的发展可能是各个行业中最快的，服务架构做为最重要的IT基础性技术之一自然也在快速地进化，所以本书也会用适当的篇幅用实例介绍目前比较业界被看好的Service Mesh及Serverless技术。
扩展丰富，追根溯源：本书以脚注或扩展阅读的形式引用了大量基础或发散性的解释说明做为知识体系的补充，引文力求正本清源，多为论文链接或权威网站（多见于Wikipedia、InfoQ、IBM）的一手资料。
实例导向，理论为辅：笔者多年服务于互联网金融公司，本书以信贷系统这一真实项目为线索，循序渐进地介绍服务架构的来龙去脉，微服务架构的基础性理念介绍是必须的，但不会生搬硬套地解释某些知识点的设计原理，而会更加关注在架构演进过程中为什么要用到这些技术及这些技术的适用场景及局限。
言简意赅，拒绝话痨：对比国内外技术书箱，很大的差异在于国内很多作者喜欢“堆代码”，喜欢“旁征博引”，本书不求“厚”，但求“精”，对于一些显而易见或是网络中已有详尽介绍的知识点本书尽量以扩展阅读的形式呈现给读者，不占用过多篇幅介绍。
内容殷实，力求全面：在保证行文紧凑的同时，本书尽量覆盖服务架构的核心点、项目实例的全流程关键点，并且会引入一些相关的扩展话题以供探讨，IT技术的发展可能是各个行业中最快的，服务架构做为最重要的IT基础性技术之一自然也在快速地进化，所以本书也会用适当的篇幅用实例介绍目前比较业界被看好的Service Mesh及Serverless技术。
扩展丰富，追根溯源：本书以脚注或扩展阅读的形式引用了大量基础或发散性的解释说明做为知识体系的补充，引文力求正本清源，多为论文链接或权威网站（多见于Wikipedia、InfoQ、IBM）的一手资料。
2021年10月30日 服务的熔断及降级是系统鲁棒性的关键之一，这与我们常听说的服务雪崩有着紧密的关系。
微服务是继SOA后，最流行的服务架构风格之一。
按照微服务对系统进行拆分后，每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的，模块之间的边界也更加清晰。
微服务有效降低了软件项目的业务复杂程度，为小团队独立开发、持续交付和部署打下了良好的基础。
遗憾的是，微服务并不是银弹。与传统的单一架构相比，微服务架构对团队的组织架构、技术水平、运维能力等方面，都提出了更高的要求。如果没有掌握得当的方法而生搬硬套，微服务架构只会会适得其反－－降低项目的开发效率，这是本书的创作初衷之一。
在国内外的技术社区中，比较推崇现有开源方案，如"Spring Cloud全家桶"或者阿里开源的"Dubbo"。上述框架通常已经实现了服务发现、配置、负载均衡、限流熔断，等微服务架构所必须的的核心功能。
使用开源框架省却了造轮子的过程，但也降低了我们学习、思考的欲望。
为什么需要服务发现，又如何实现它呢？配置中心呢....思考和设计的过程充满了挑战，也是提升自身架构能力的一种手段。这是本书的创作初衷之二。
已有的微服务资料过于重视微服务的开发，忽略了微服务赖以生存的生态系统：工具链、自动化运维。可以说，离开了这两点的支持，微服务架构将难以落地。完善这两方面的思考和实战，是本书的创作初衷之三。
为此，我撰写了这本《从0到1实战微服务架构》。让我们"暂时忘掉"已有的、成熟的开源解决方案。尝试亲自动手，实现微服务架构的各个模块。
我们会从微服务开发、工具链、运维这三个角度，阐述微服务架构的实战方案。
由于篇幅、精力所限，本书无法写成一本”零起点”教程。我假设读者具有至少2年的服务端工作经验，并且了解以下技术或原理：
Git
Maven & Gradle
Docker & k8s
Java
Spring / Spring Boot
数据库: 如MySQL
消息队列: 如RabbitMQ
缓存系统: 如Memcached
内存数据库: 如Redis
本书可以供架构师、项目经理、高级服务端程序员参考、学习。
动手实战是本书的核心内容，因此本书所涉及的全部代码，都托管到了我的Github上(以lmsia-开头的项目)。
这些代码以研讨为主要目的，也可以直接应用于生产，但本人不对其稳定性负责。
按照微服务对系统进行拆分后，每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的，模块之间的边界也更加清晰。
微服务有效降低了软件项目的业务复杂程度，为小团队独立开发、持续交付和部署打下了良好的基础。
遗憾的是，微服务并不是银弹。与传统的单一架构相比，微服务架构对团队的组织架构、技术水平、运维能力等方面，都提出了更高的要求。如果没有掌握得当的方法而生搬硬套，微服务架构只会会适得其反－－降低项目的开发效率，这是本书的创作初衷之一。
在国内外的技术社区中，比较推崇现有开源方案，如"Spring Cloud全家桶"或者阿里开源的"Dubbo"。上述框架通常已经实现了服务发现、配置、负载均衡、限流熔断，等微服务架构所必须的的核心功能。
使用开源框架省却了造轮子的过程，但也降低了我们学习、思考的欲望。
为什么需要服务发现，又如何实现它呢？配置中心呢....思考和设计的过程充满了挑战，也是提升自身架构能力的一种手段。这是本书的创作初衷之二。
已有的微服务资料过于重视微服务的开发，忽略了微服务赖以生存的生态系统：工具链、自动化运维。可以说，离开了这两点的支持，微服务架构将难以落地。完善这两方面的思考和实战，是本书的创作初衷之三。
为此，我撰写了这本《从0到1实战微服务架构》。让我们"暂时忘掉"已有的、成熟的开源解决方案。尝试亲自动手，实现微服务架构的各个模块。
我们会从微服务开发、工具链、运维这三个角度，阐述微服务架构的实战方案。
由于篇幅、精力所限，本书无法写成一本”零起点”教程。我假设读者具有至少2年的服务端工作经验，并且了解以下技术或原理：
Git
Maven & Gradle
Docker & k8s
Java
Spring / Spring Boot
数据库: 如MySQL
消息队列: 如RabbitMQ
缓存系统: 如Memcached
内存数据库: 如Redis
本书可以供架构师、项目经理、高级服务端程序员参考、学习。
动手实战是本书的核心内容，因此本书所涉及的全部代码，都托管到了我的Github上(以lmsia-开头的项目)。
这些代码以研讨为主要目的，也可以直接应用于生产，但本人不对其稳定性负责。
2021年11月02日 在本节，我们将讨论"熔断"方案的思路及其在微服务架构下的落地。