目录
微服务概念这两年越来越火爆，也有公司开始进行微服务项目迁移，很多开发者开始接触微服务开发。
本章会介绍一些微服务的基础概念，并且通过一系列的示例逐步接触 Spring Cloud 的各个常用组件，为后面的代码编写做好准备。
1.1 第一次听说
“微服务”这个词现在只要是做开发的人基本都听过了，看到本书的时候基本都谈不上“第一次”了。但是从第一次听到这个概念到现在我们对微服务都有过什么样的了解呢？到底什么才是微服务呢？
1.1.1 什么是微服务
关于到底什么是微服务，每个人都有自己的见解。大家可以在网上搜索参考各位大牛的说法。
笔者认为微服务就是将系统按照某个固定的维度进行独立开发、独立存储、独立部署、独立运行，达到资源的隔离和团队的隔离。在这个基础上，微服务框架需要考虑到微服务化后的一些非业务性需求。比如服务发现、服务调用、服务监控等。
每一个微服务都应该是可以独立开发，独立部署、升级的。并且每个服务相对之间没有技术依赖性，彼此的技术应该是互不干扰的。
注意：记住上面提到的固定维度，这个会是后期微服务架构施行的一个难点—拆分服务。同时，请记住一点，微服务的“微”并不是物理大小，而是从业务角度来讲的某个最小固定维度。
1.1.2 为什么要用微服务
微服务可以将现有的一些单一臃肿的程序从一个JVM上解脱出来，让每个功能（微服务）独立工作，对系统进行解藕，各个拆分出来的微服务运行在自己独立的JVM上，相互之间完全独立。这样不但可以让各个微服务在运行时不互相影响，更可以将开发团队进行区分，避免一堆人改一块代码。
独立部署不仅仅是对系统进行解藕，更是可以让我们灵活地对不同的服务来进行技术选择、优化硬件投入，从而降低系统整体成本。近几年来，国内外的公有云、私有云都红火了起来，在各种云的加持下，如果还用原来的单体程序，就有点浪费了。使用微服务，可以让团队更专注地在短时间内迭代出市场需要的功能，并且可以快速发布，不断根据需求迭代特定服务，占取先机。
微服务架构的出现是软件架构的一个必然发展过程。软件架构由单纯的单体应用架构，到垂直分类架构，再到SOA架构，直到目前的微服务架构，每一步都在不断地解决上一个架构风格所带来的问题。
单体应用架构有着天然的简单性，所有的功能都集中在一个程序包中，前期开发成本低，非常小企业、小型项目使用。但是当项目逐渐变大后，系统就面临着维护成本高，开发难度高，不容易扩展等问题。
垂直分类架构将系统按照功能垂直分类，分离后的每个应用按照单体应用架构构建，可以构成集群，但是集群本身有其自身的一些限制，并且本质上还是单体应用架构，所以单体应用架构所存在的问题垂直分类架构都存在，只是它的各个系统变“小”了，所以问题出现的时间略有延后。同时因为垂直的分类，各个拆分后的应用之间还多出了很多的数据冗余，功能耦合。
在这个基础上，SOA架构出现了，SOA架构为了解决上面的问题，提出将应用做成一个个的服务，将系统中的功能进行抽取，构建一个个的服务，但是并没有从本质上解决系统耦合的问题，抽取出来的服务之间提出了松耦合的概念，但是因为服务间的界限仍然模糊，服务之间的耦合依然大量存在。
注意：微服务严格的划分了各个服务之间的界限。
如图1.1所示，标示了单体架构和微服务的结构对比情况。
微服务架构在成熟框架的支持下，将系统按照服务拆解，并且每个服务可以单独进行集群部署、灵活伸缩。服务之间通过既定的HTTP或者RPC方式进行通信。
注意：HTTP和RPC只是使用频率比较高的方案而已，还有TCP，MQS等方式的传输。
对于微服务架构的流行，带来的好处不单单是技术上的。笔者认为更多的是在开发团队上带来的变革。微服务架构的不断成熟，让系统在拆分成各种微服务后，可以由独立的开发团队来快速迭代，加快产品发布周期。
简单总结微服务的优点：
- 易于开发、维护；
- 独立部署、升级；
- 可以独立根据需要扩容；
- 独立团队责任，提高团队单个生产力。
1.1.3 微服务有不足吗
微服务有不足吗？当然有，主要有以下几点：
- 复杂。
- 运维难度大。
- 性能有一定程度会变低。
单体程序再复杂，初写起来相对来说都比较简单。可是微服务在进行服务拆分的时候就会有各种各样的问题困扰着我们。拆分好后，开发阶段也会面临人员技能等一系列的问题。
微服务拆开后运维会变得越来越复杂，一个中型项目，如果有10个微服务，每个微服务平均部署5～8个实例。如果再有几套开发环境，线上再搭配几套灰度环境。这个数量就已经很可观了。运维人员以前只需要管理一台机器，最多也就几台机器组成的集群。可是微服务化后，运维的工作增加了一倍不止。
微服务间的调用方式不管是使用RPC还是HTTP，都不如进程内的调用快。在一些对性能要求特别高的系统中，使用微服务项目一定要慎重。
即使性能要求不高的系统，如果单体程序可以满足，并且可以很好地满足自身的业务需要，那么进行微服务切换并不是一个明智的选择。
微服务并不是万能的！使用微服务之前一定要根据自己的业务选择，万不可盲目跟风。
注意：这里的性能问题只是相对来说，HTTP请求的性能应对大部分的现存系统都是完全够用的。具体到项目中是否要使用微服务架构，还是要根据实际情况来说，就目前的情况来说，大部分的系统使用微服务架构都没有问题。
如果你的项目确认要使用微服务，那么加油，希望大家都能享受到微服务思想带来的便利。
1.2 第一次学习
对微服务有了一些基本了解后，接下来就要开始走进微服务的世界里。
1.2.1 如何选择首次接触的微服务框架
开发框架的选择对文档、背景、社区以及架构的整体完整性都应该有一定的要求。选择一个有大公司做背书，且文档完善，社区活跃的框架最好不过，如果这个框架整体还很完整，为开发人员想好了各种方案以及后路，那么这个框架对我们来说就是一个很好地选择。
微服务发展到现在，阿里的Dubbo，腾讯的Tars，新浪的Motan，Pivotal的Spring Cloud……
本系列选择并推荐Pivotal的Spring Cloud框架，Pivotal公司的Spring Framework深入人心，Spring及其衍生框架已经成为Java企业级开发的基本官方事实，在Spring Framework的基础上推出了Spring Boot框架，以Spring Boot框架为基础，又推出了Spring Cloud这个微服务框架作为微服务架构的一个类官方解决方案。
注意：本系列会将重心放在后面的主体内容，各个框架的对比可以在网络上搜索各家官网进行对比，这里不做过多说明。
1.2.2 怎样才算用到微服务
微服务框架包括了服务治理、服务健康检查、服务调用、服务熔断、配置管理等一系列功能。目前不少公司都在做微服务转型，尝试将现有的单体大程序转换成微服务架构。在这个过程中，一蹴而就基本不可能，笔者建议按需取用、适用为主，先从某个不重要的业务开始，积累微服务化经验。甚至于有的系统都不需要一定要真的用到框架里面的所有，也许采用框架中的某一个组件，甚至于某一处思想，只要能解决当前的问题就好。
用微服务，并不单纯是用框架，重要的是理解其中的思想。微服务结构本身并不是什么新技术，只是一种比较新的架构思想，仅此而已，不要神话它。
1.2.3 我要朝着什么样的方向学习
以某一个框架为基础，通过一些简单的练习熟悉框架的使用，在这个过程中，慢慢领会框架中蕴含的架构思想，并吸收消化后供自己使用。领会思想并且熟练使用后，对这个架构体系中的部分问题进行深入思考，总结出自己对这个架构体系的理解。
微服务使用过程中将会面临一系列的问题：
- 服务拆分；
- 数据一致性；
- 服务通信；
- 安全；
- 完善的监控。
在我们的学习、使用过程中，就是一个一个解决问题的过程。
1.2.4 首次使用，我要注意什么
刚开始接触微服务，不要被微服务的名字吓到。微服务本身并没有什么新的技术，他只是一种架构方案，至于为什么涉及到的技术对我们来说都像是新技术，这个只是因为以前的我们并没有关注这些技术栈。
对于Spring Cloud来说，Spring团队将经过项目检验过的项目进行了封装，将多个开源产品进行二次封装，提供给我们一系列开箱即用的Starter。
首次使用，不要太纠结于框架底层的东西，先用起来。用起来后才会慢慢对框架有自己的一些认识，才能有能力去探究框架的实现原理，研究框架中涉及的“高端”问题。
1.3 小结
作为全系列的第一章，本章使用尽可能简单的语言介绍了微服务。通过本章的学习，只需要明白微服务只是一个架构思想，我们在学习的时候不需要有任何的思想负担，由浅到深，一点点学习、使用、研究即可。