先谈下书，要说“揭秘”，大概就是第二章 spring 的原理和第三章 spring boot 启动过程算是，这两章我觉得分析的比较透彻，也是最切题的。后面的章节都是总结性的概述，所以看有评论说只是大篇幅的拷代码，代码还只是构想，倒也没全错，但因为书里提到的大部分技术点都是生产上已经在用的，所以只是跟着读一遍过一下思路就行。这里提供一个[github库](https://github.com/wacai)，上面有几个 spring-boot-starter 的项目，是当时作者所在团队的，也是我们生产环境在用的一些功能组件的 fork 的库。这些代码是经过实际验证过的，对书中例子有敲代码欲的可以参考。
springboot 框架的理念是自动配置（Auto Configuration），将 spring 传统的约定优先配置的思路（Conversion Over Configuration）进一步发扬，看懂以上部分会发现 springboot 在源码实现上也没什么稀奇的。但 springboot 提供的还是基础能力和总体构建应用的思路，只有 spring 社区快速跟进，各种各样的 spring-boot-starter 不断涌现，进而形成生态才是这个框架能够持续的关键。
第四五六章对涉及到的相应技术点都是蜻蜓点水般的入门介绍，其实本来这些也不是 springboot 的核心，要理解 springboot 所要解决的痛点是原先 spring 集成各种框架时的繁琐配置和版本库的依赖问题。我认为这三章的内容不能孤立的看，而是要放到微服务的架构风格之下，其所在的整个技术栈体系里才能更有收获。
微服务这 buzz word 我印象中大概喊两年多了，当时还在前公司做通信行业软件的一个SOA 项目，那会儿看了一阵介绍文章，没觉得和 SOA 有多大区别，仅从抽象的理解上更小一点，但对怎么落地没具体思路，更谈不上采用微服务体系之后一系列的自动化工具和平台的打造。直到去年来到一家做电商的互联网公司，用的是 springboot + dubbo 的微服务架构，其间除了日常业务开发外，也参与了一些自动化工具的搭建，走过弯路也有点心得，回过头再看[马丁福勒大叔的那篇文章](https://martinfowler.com/articles/microservices.html)境界又不一样。
微服务定义：
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
简而言之，微服务架构风格是就是开发一个单独的应用程序作为一系列小的服务的方法，每一个服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP API 。这些服务围绕业务能力来构建并通过全自动部署机制独立部署。它们有最低限度的集中管理，可能会采用不同的编程语言和数据存储技术。
说白了就是尽量将功能拆分，服务粒度做小，可以让这些服务独立对外提供功能，按这种思路开发交付软件的就是微服务。其背景是单体应用（monolithic application，就是以前那种将很多功能打包成一个大的服务单元整体进行交付的应用）不能满足更高复杂度下对服务治理、运维、自动化基础设施的要求。因为随着系统复杂度的持续升高，需要支持在整个软件交付链路上更高效扩展，势必将独立的功能和服务进行拆分，从而演化成一个个微服务。这种思路带来的好处就是独立，跳出了原来大一统的王国统治，可以从开发、编译部署、发布、监控等各个层面打造自己的独立的能力，从而保障自己持续稳固的运行。
那么怎么独立，springboot 提供的就是一种将该思路落地的方案。通过它来将概念上拆分后的服务单独开发测试部署，但这只是微服务理念实践的起点，微服务的核心竞争力是围绕整个软件交付链路提供一整套支撑工具和平台。包括开发阶段的标准化的开发体验、统一的发布和管理、进而通过标准化的方式统一维护数量庞大的服务等等。这些涉及应用间的通信机制，应用的发布、部署、监控、运维等一系列自动化工具平台的打造。将服务拆解，复杂度降低只是面对更高复杂度应用的解题思路，而如何运用计算机将重复的事情变成自动的，用电力来节省人力，能提供一套在软件生命周期各个节点自动化的方案才是微服务理念真正落地。也只有实现了这些基础设施，微服务的理念才显现出威力。
关于实践中的一些坑：
1.分布式事务问题。应用拆分之后难免会碰到一些场景需要跨服务但又需要保证事务一致性，所以大叔才说分布式事务非常难以实施，因此微服务架构强调服务间事务的协调，并清楚的认识一致性只能是最终一致性以及通过补偿运算处理问题。（Distributed transactions are notoriously difficult to implement and and as a consequence microservice architectures emphasize transactionless coordination between services, with explicit recognition that consistency may only be eventual consistency and problems are dealt with by compensating operations.）
这点可以参考之前谈过的[分布式事务问题的一次讨论](http://www.jianshu.com/p/b5e3e2385d04)
2.自动部署的问题。现在很多中小企业基于云上构建应用，这降低了构建、发布、运维微服务的复杂性，微服务的理想目标便是持续集成、持续部署，哪个应用需要升级了直接推到master 上，自动化测试跑通后就发布到生产。但这个目标涉及应用（或者说是进程、微服务）的优雅停止启动，springboot 本身提供了一些优雅关闭的方案，但它只是对自身（由springboot）产生线程的资源释放和应用关闭的方案，如果应用所处的网络层架构比较复杂，还涉及到与整体架构最前端的负载均衡通知停止发送请求、应用集成的分布式服务（比如dubbo）降权、应用自身产生的定时任务线程的监控与关闭、应用与消息队列的启停通信等，需要对所有涉及应用的线程做整体的梳理、区分，才能实现真正的优雅启停，进而达到持续部署的效果。
网友评论