作者：黄勇
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
轻量级微服务架构(上册)试读：
前言
微服务是近年来备受关注的话题，它的出现让我们想起了十年前的SOA（Service-Oriented Architecture，面向服务架构），但它比传统的SOA更容易理解，也更容易实践，它将“面向服务”的思想做得更加彻底。
当国外一些知名技术公司成功实践了微服务以后，这股热潮就吹遍了国内的大街小巷，大家街头巷尾都在聊微服务，对它众说纷纭且褒贬不一。有人说它非常好，但就是“玩不起”，为何会这样呢？
我们不妨带着这个问题来简单介绍一下，究竟什么才是微服务。
微服务是一种分布式系统架构，它建议我们将业务切分为更加细粒度的服务，并使每个服务的责任单一且可独立部署，服务内部高内聚，隐含内部细节，服务之间低耦合，彼此相互隔离。此外，我们根据面向服务的业务领域来建模，对外提供统一的API接口。微服务的思想不只是停留在开发阶段，它贯穿于设计、开发、测试、部署、运维等软件生命周期阶段。
可见，我们提到的微服务，实际上是一种架构思想，我们不妨称它为“微服务架构”。
微服务架构看起来如此之好，我们真的就需要它吗？
微服务架构建议我们按照业务来切分服务，我们完全可以选择最合适的技术来实现具体的服务，只需确保对外提供的API接口保持一致即可，也就是说，微服务架构使我们技术选型的自由度更加宽广了。既然系统可拆分为多个服务，这样非常有利于我们对每个服务进行监控，可不断收集每个服务的性能指标数据，当某个服务出现性能瓶颈时，会发出预警，我们可随时水平地扩展该服务，以支撑更大的流量，而不至于复制整个系统。由于服务之间彼此隔离，相互之间不会产生影响，因此我们可借助技术的手段来实现自动化部署，这会使我们的部署过程变得更加高效。
其实微服务架构的优点数不胜数，但是大家可能还是不敢用，因为它对我们的技术要求具有一定的挑战。比如，我们需要一个自动化部署系统，也需要解决分布式系统带来的一系列问题，还需要服务之间能做到彼此隔离且互不影响，同时还不能影响通信过程中所带来的性能开销。因此很多人认为，只有大公司或强悍的技术团队才能玩得起微服务架构，自己只能“远观”却不能“近玩”。甚至还有人认为，微服务架构实际上就是以前谈论多年而难以落地的SOA。
实际上，我们认为微服务架构的本质仍然符合SOA思想，只不过它比SOA更容易落地。为了证明这件事情，我们经过了大量的实践，借助了许多优秀的开源技术，搭建了一款“轻量级微服务架构”。实践证明，该架构不仅可以适应大中型公司的业务变化，还能满足中小型公司的快速增长。我们真心地希望这款轻量级微服务架构能够帮助更多的技术爱好者以及更多的技术团队，顺利地走出技术困境，以全新的视角去迎接新的挑战。
不得不提醒大家的是：微服务并不是万灵丹！它不能包治百病，我们更不要为了微服务而去微服务。而是需要根据自身的情况，灵活地选择最合适的技术，通过技术的手段实现更高的目标。为什么写这本书？
我一直很关注服务化方面的技术，记得在2014年，我偶然发现国外技术博客中有人在写关于“微服务”方面的概念与技术。坦白地讲，当我第一次看到微服务时，并没有对它产生浓厚的兴趣，我当时认为微服务是笨重的，它和传统的SOA没有太大的区别，同样都是服务化，只不过微服务更加细粒度而已。直到Docker容器技术逐步成熟起来，越来越多的人开始使用Docker来封装应用程序，并借助Docker技术让软件交付变得更加灵活而高效，这让我不由地对微服务的未来产生了强烈的期待，我坚信微服务将伴随着Docker技术成为未来软件开发与运维的核心武器。
我开始疯狂地学习微服务，研究它的各种架构模式与应用领域，开始自己动手做一些练习，并在公司内部大力推广这种新架构。在实践中，我获得了一点收获，曾在一些技术大会与企业内训中讲过微服务的原理与实践。我发现一个问题，虽然大家对微服务都非常关注，但往往却不知应该如何开始，应该使用哪些技术来搭建微服务架构，以及在实践中应该如何避免掉进坑里。甚至有些人还认为微服务只是大公司才玩得起的东西，因为它需要借助像SOA那样重量级的基础设施，需要付出大量的成本，但收益却不一定。其实，我想告诉大家的是，微服务架构并非这样，它应该是轻量级的，它应该是很容易上手的，它应该是任何公司想用就敢用的。虽然国内外已经有几本关于微服务方面的好书了，但我仍然希望这本书能为大家在微服务实践方面带来微薄的价值。
我们可以把微服务架构想象成海面上的一座冰山，看得见的部分是开发，看不见的部分是运维，一个好的微服务架构需要同时关注开发和运维两个方面。本系列书分上下两册，上册偏开发，下册偏运维。您适合看这本书吗？
如果您还没听说过微服务，或者您听说了但不知道它究竟是什么，或者您正在尝试微服务的实践，那么这本书就非常适合您。不管您是一名开发人员还是一名运维人员，如果您向往成为一名优秀的微服务架构师，那么这本书更加值得您反复阅读和实践。本书是如何组织的？
第1章：微服务架构设计概述。
从为什么需要微服务架构开始讲起，接着描述微服务架构是什么，以及微服务架构有哪些特点，最后以如何搭建微服务架构来结束本章。本章是全书的概述，从一个宏观的视角来讲解微服务，为后续章节搭建了一个骨架。
第2章：微服务开发框架。
本章我们将使用流行的Spring Boot来搭建微服务开发框架，对Spring Boot是什么，以及如何使用Spring Boot都做了描述，此外还对Spring Boot的重要产品级特性做了相关介绍。通过学习本章，大家可掌握Spring Boot的基本使用方法，并具备开发微服务接口的技能。
第3章：微服务网关。
本章我们将学习Node.js技术，描述Node.js是什么，以及如何使用Node.js，此外还对Node.js的重要高级特性做了补充。最后我们将使用Node.js搭建一个微服务网关基础框架，后续章节会对此框架进行扩展。
第4章：微服务注册与发现。
本章我们将学习ZooKeeper框架，从认识ZooKeeper开始，到如何使用ZooKeeper。最后我们将使用ZooKeeper实现一个简单的服务注册组件，并结合第3章中介绍的微服务网关框架，使用Node.js实现一个服务发现组件。
第5章：微服务封装。
本章我们将学习Docker技术，从了解Docker是什么开始，到如何使用Docker，并通过手工和Dockerfile的方式构建Docker镜像，此外还会介绍Docker Registry的使用方法，最后将以Spring Boot与Docker做一个整合来结束本章。通过学习本章，大家可熟练使用Docker，为后续自动化运维提供基础。
第6章：微服务部署。
本章是上册的最后一章，我们将使用Gitlab管理项目源码，使用Jenkins搭建持续集成系统，最后基于Jenkins + Gitlab + Docker搭建一款微服务的自动化部署平台。通过学习本章，大家可将开发与部署更加高效地衔接起来。我要致谢的人
我要把这本书送给我的女儿，虽然她根本就看不懂，因为她只有三岁。记得在她刚出生那年，我开始写技术博客；在她一岁那年，我开始做开源项目；在她两岁那年，我开始写自己的第一本书；在她三岁之时，这本书出版了。为了自己的事业，我借用了陪伴她成长的时间，这个时间是我这辈子都无法偿还给她的，希望她长大后能看到我送给她的这本书，或许她会理解我现在所做的一切。
我最想感谢的人还是我的妻子，她为了料理家务和照顾女儿，选择放弃自己的事业，全力支持我的事业，这种“放弃自己，成全他人”的精神，我是无法做到的。我有这样的好妻子，让我感到无比骄傲，同时我也需要给自己更高的目标，回报她对我的付出。
十年前我离开自己的家乡，独自来到上海打拼，这些年很少陪伴在自己父母的身边，因为工作太忙而遗忘了对父母的问候，我很愧疚自己所做的一切。感谢我的父母对我的无私付出，以及对我事业的认可与鼓励，希望他们看到这本书后能为我感到高兴。
感谢与我一起创业的伙伴们，大家能在一起共事是一种缘分，他们在工作上给我提供了许多帮助，和他们一起工作是我最开心的事情，我也能感受到自己在成长。他们还为本书提供了专业的建议，以及为本书提供了大量宝贵的实践经验。
感谢电子工业出版社博文视点的陈晓猛编辑，在写作过程中晓猛多次鼓励我，他曾说“写书就是登山”，每当我写不动了，想放弃了，他就会鼓励我“快到山顶了”，他无形中成为了我的“鼓励师”，让我顺利地写完了这本书。
感谢为这本书做评审的专家们，他们的专业态度让我非常感动。为了给读者提供更多的价值，他们给我提供了大量的建议，这些建议对我的帮助非常大，让我在后续写作道路上更有经验了。
感谢一直支持我的读者们，没有你们一路的陪伴，我会失去写作的动力和方向。
最后我想说的是：我并不是微服务架构专家，我只是一名微服务架构的实践者，只想把自己实践的经验分享给大家。由于本人学识有限，难免会有不足之处，还请读者不吝赐教。黄勇2016年7月27日于上海第1章微服务架构设计概述
自从Martin Fowler（马丁）在2014年提出了Micro Service（微服务）的概念后，业界就卷起了一股关于微服务的热潮，大家谈论多年的SOA（Service-Oriented Architecture，面向服务的架构）终于有了新的解决方案，人们不再需要笨重的ESB（Enterprise Service Bus，企业服务总线）。恰逢Docker技术逐渐普及，一个崭新的轻量级SOA架构MSA（Micro Service Architecture，微服务架构）伴随着Docker容器技术正向我们携手走来。1.1 为什么需要微服务架构
微服务架构（MSA）的出现绝对不是偶然的，由于传统应用架构的不合理，从而产生了新的架构模式，这类现象再正常不过了。那么，传统应用架构究竟有哪些问题呢？下面为大家做一个简单的分析。1.1.1 传统应用架构的问题
图1-1是一个经典的Java Web应用程序（见图中Webapp），它包括Web UI部分，还包括若干业务模块，就像这里出现的Module A、Module B、Module C等。图1-1 传统应用架构
Web UI与这些Module封装在一个war包中，需要将此war包部署到Web Server（例如Tomcat）上才能运行，该应用程序会连接到Database（例如MySQL）上操纵数据。
在系统运行过程中，我们通过监控程序发现，Module A与Module B都需要消耗10%的系统资源，加起来才占总系统资源的20%，而Module C却要占用80%的系统资源。运行一段时间后，Module C就会成为整个系统的瓶颈，从而降低系统的性能。
那么，如何才能解决这类问题呢？人们想到了一个简单的办法。1.1.2 如何解决传统应用架构的问题
只需将这个应用程序复制一份同样的程序，并将其部署到另一台Web Server上，下方还是连接到同样的Database，只是在这些Web Server的上方架设一台Load Balancer（负载均衡器，简称LB），可见应用程序进行了“水平扩展”，如图1-2所示。图1-2 传统应用架构——水平扩展
请求会先发送到LB上，通过LB上的路由算法（例如轮询或哈希），将请求转发到后面具体的Web Server上，这类请求转发技术被称为Reverse Proxy（反向代理）。
由于进入LB的请求（流量）被均衡到下方各台Web Server中了，流量得到了分摊，负载得到了均衡，因此该技术也称为Load Balance（负载均衡）。
如果流量加大，我们还可以继续水平扩展更多的Web Server，该架构理论上可以无限扩展，只要LB扛得住巨大的流量就行。
通过以上技术方案，轻松地将负载进行了均衡，在一定程度上缓解了流量对Web Server的压力，但此时却造成了大量的系统资源浪费，比如对系统资源占用率不高的Module A与Module B也进行了水平扩展，其实我们只想对Module C进行水平扩展而已。
除了水平扩展方案带来的系统资源浪费，实际上传统应用架构还有其他问题，下面我们继续讨论。1.1.3 传统应用架构还有哪些问题
传统应用架构实际上是一个Monolith（单块架构），因为整个应用都封装在一个Webapp中，就像是巨石一块，无法拆分，我们所做的水平扩展也只是在扩展一块块的巨石。为了便于表达，我们不妨将单块架构搭建的应用简称为“单块应用”。
我们在部署单块应用的时候，同样也会遇到许多麻烦，比如：● 修改了一个Module（可能只是修改了一行代码），就需要部署整
个应用；● 部署整个应用所消耗的时间与对系统带来的性能开销都是非常多
的。
此外，对于Java Web应用而言，打包在war包里的代码一般都是class文件，这也就意味着，我们的单块应用只是基于Java语言开发的，无法将该应用中某个Module通过其他开发语言来实现（假如我们不考虑在JVM上运行动态语言的情况下），也许其他开发语言实现某个模块会更加合适，这样就会产生技术选型单一的问题。
综上所述，传统应用架构存在以下问题：● 系统资源浪费；● 部署效率太低；● 技术选型单一。
当然，传统应用架构的问题还远远不止这些。当业务变得越来越复杂时，应用会变得越来越臃肿，“身材”越来越“胖”，而且无法瘦身。于是，人们找到了新的思路来解决传统应用架构的问题，这就是微服务架构。
那么，微服务架构究竟与传统应用架构有何区别呢？我们接着探讨。1.2 微服务架构是什么
微服务架构从字面来理解就是：许多微小的服务搭建的应用架构。
这句话涉及了许多问题，我们需要逐一探讨，比如：● 服务需要多“微”才能叫微服务？● 如何管理越来越多的微服务？● 客户端怎样调用这些微服务？
我们带着这些问题，开始下面的讨论，首先我们来看看如何定义微服务架构。1.2.1 微服务架构概念
当马丁大神提出微服务架构这个概念时，同时他也对微服务架构提出了几条要求，也就是说，当我们的应用满足以下要求时，才能称为微服务架构，具体要求包括：● 根据业务模块划分服务种类；● 每个服务可独立部署且相互隔离；● 通过轻量级API调用服务；● 服务需保证良好的高可用性。
我们简单地分析一下：首先根据产品的业务功能模块来划分服务种类，也就是说，我们需要按照业务功能去划分种类，这是“垂直划分”；而在代码层面进行划分，这是“水平划分”。每个服务可以独立部署，还需要相互隔离，也就是说，服务之间是没有任何干扰的，可将每个服务放入独立的进程中运行，因为进程之间是完全隔离的。客户端通过轻量级API来调用微服务，比如可通过基于HTTP或RPC的方式来调用，目的是为了降低调用所产生的性能开销。服务需要确保高可用性，不能长时间无法响应，需要提供多个“后补队员”，在某个服务出现故障时，可以自动调用其中一个正常工作的服务。
微服务架构颠覆了传统应用架构的模式，若不定义良好的交付流程与开发规范，则很难让微服务架构发挥出真正的价值，下面我们先来看看微服务架构的交付流程。1.2.2 微服务交付流程
使用微服务架构开发应用程序，我们实际上是针对一个个微服务进行设计、开发、测试、部署，因为每个服务之间是没有彼此依赖的，大概的交付流程如图1-3所示。图1-3 微服务交付流程
在设计阶段，架构师将产品功能拆分为若干服务，为每个服务设计API接口（例如REST API），需要给出API文档，包括API的名称、版本、请求参数、响应结果、错误代码等信息。在开发阶段，开发工程师去实现API接口，也包括完成API的单元测试工作。在此期间，前端工程师会并行开发Web UI部分，可根据API文档造出一些假数据（我们称为“mock数据”）。这样一来，前端工程师就不必等待后端API全部开发完毕，才能开始自己的工作。在测试阶段，前后端工程师分别将自己的代码部署到测试环境上，测试工程师将针对测试用例进行手工或自动化测试，随后产品经理将从产品功能上进行验收。在部署阶段，运维工程师将代码部署到预发环境中，测试工程师再次进行一些冒烟测试，当不再发现任何问题时，经技术经理确认，运维工程师将代码部署到生产环境中，这一系列的部署过程都需要做到自动化，才能提高工作效率。
需要注意的是，以上过程看似需要多种角色的工程师参与，实际上并非每种角色都对应具体的工程师。往往在小团队里，一名工程师可兼任多种角色，这些都是正常现象。只是对于大团队而言，分工比较明确，更容易实施这套交付流程。
在以上交付流程中，开发、测试、部署这三个阶段可能都会涉及对代码行为的控制，我们还需要制定相关的开发规范，以确保多人能够良好地协作。1.2.3 微服务开发规范
无论使用传统应用架构，还是微服务架构，我们都需要定义良好的开发规范。经验表明，我们需要善用代码版本控制系统。就拿Git来说，它很好地支持了多分支代码版本，我们需要利用这个特性来提高开发效率，图1-4就是一款经典的分支管理规范。图1-4 微服务开发规范
最稳定的代码放在master分支上（相当于SVN的trunk分支），我们不要直接在master分支上提交代码，只能在该分支上进行代码合并操作，例如将其他分支的代码合并到master分支上。
我们日常开发中的代码需要从master分支上拉一条develop分支出来，该分支所有人都能访问，但一般情况下，我们也不会直接在该分支上提交代码，代码同样是从其他分支合并到develop分支上去的。
当我们需要开发某个特性时，需要从develop分支上拉出一条feature分支，例如feature-1与feature-2，在这些分支上并行地开发具体特性。
当特性开发完毕后，我们决定发布某个版本了，此时需要从develop分支上拉出一条release分支，例如release-1.0.0，并将需要发布的特性从相关feature分支一同合并到release分支上，随后针对release分支部署测试环境，测试工程师在该分支上做功能测试，开发工程师在该分支上修改bug。待测试工程师无法找到任何bug时，我们可将该release分支部署到预发环境中。再次验证以后，如无任何bug，此时可将release分支部署到生产环境中。待上线完成后，将release分支上的代码同时合并到develop分支与master分支上，并在master分支上打一个tag，例如v1.0.0。
当在生产环境中发现bug时，我们需要从对应的tag上（例如v1.0.0）拉出一条hotfix分支（例如hotfix-1.0.1），并在该分支上进行bug修复。待bug完全修复后，需将hotfix分支上的代码同时合并到develop分支与master分支上。
对于版本号我们也有要求，格式为：x.y.z，其中，x用于有重大重构时才会升级，y用于有新的特性发布时才会升级，z用于修改了某个bug后才会升级。
针对每个服务的开发工作，我们都需要严格按照以上开发规范来执行。
实际上，我们使用的开发规范是业界知名的Git Flow，可通过以下博客地址了解Git Flow的详细过程：
http://nvie.com/posts/a-successful-git-branching-model/。
此外，在GitHub中有一个基于以上Git Flow的命令行工具，名为git-flow，其项目地址如下：
https://github.com/nvie/gitflow。
我们已经对微服务架构的概念、交付流程、开发规范进行了描述，下面我们大致归纳一下微服务有哪些特点。1.2.4 微服务架构模式
世界著名软件大师Chris Richardson（克里斯）创建了一个总结微服务架构模式的网站。该网站上列出了大量的微服务架构模式，分为：核心模式、部署模式、通信模式、服务发现模式、数据管理模式等。该网站地址如下所示。
微服务架构模式网站：http://microservices.io/。
我们将在本书中借鉴许多克里斯总结的微服务架构模式，也会对某些设计模式加以变化，使之变得更加容易落地。
克里斯也是Cloud Foundry的创始人，微服务架构领域的世界级权威，他经常会来中国为我们分享他的宝贵经验。1.3 微服务架构有哪些特点和挑战
微服务架构相对于传统应用架构有着显著的特点，同时微服务架构也给我们带来了一定的挑战，我们先从它的特点开始说起。1.3.1 微服务架构的特点1．微小度颗粒
微服务的粒度是根据业务功能来划分的，对于某些复杂的业务来说，可能粒度较大，对于相对简单的业务而言，可能粒度较小。总之，微服务的粒度可大可小，但往往我们更希望它尽可能的小，但又不希望微服务之间有直接的依赖，因此粒度的划分是一件非常考验架构师水平的事情。2．责任单一性
我们需要确保每个微服务只做一件事情，也就是我们经常提到的“单一职责原则”，该原则对微服务的划分提供了指导方针。如果我们将一个服务提供多个API，那么就要确保每个API必须做到责任单一性。3．运行隔离性
每个服务相互隔离，且互不影响。也就是说，每个服务运行在自己的进程中。众所周知，进程之间是隔离的，是安全的，而进程内部或线程之间的资源是共享的。换句话说，一个服务出了问题，不会影响到其他微服务。4．管理自动化
随着业务功能不断增多，服务的数量也会逐渐增加，我们需要对服务提供自动化部署与监控预警的能力，这样才能更加高效地管理这些服务。需要注意的是，我们必须借助自动化技术，才能确保管理服务变得更加容易。
微服务架构的特点非常明显，可能还有很多，但同时微服务架构也给我们带来了许多挑战。1.3.2 微服务架构的挑战1．运维要求较高
运维工程师除了需要使用自动化技术来部署微服务，还需要对整个微服务系统进行有效的监控，并保障系统的高可用性。可见，微服务架构的引入会带来运维成本的上升。2．分布式复杂性
微服务架构的本质还是一个分布式架构，每个服务可以部署在任意的机器上。对于分布式系统而言，网络延迟、系统容错、分布式事务等问题都会给我们带来很大的挑战。3．部署依赖较强
对于业务复杂的情况，可能存在多个服务来共同完成一件事情，服务之间虽然没有相互调用，但可能会有调用的顺序性要求。业务上的依赖性导致了部署的依赖性，从而在某一时间点，同一微服务可能具备多个版本。4．通信成本较高
既然服务是隔离在自己的进程中运行的，那么从客户端调用微服务，需要跨进程间进行调用，而进程间的调用一定比进程内的调用更加消耗资源，从而带来通信成本上的开销。1.4 如何搭建微服务架构
可见，微服务架构的要求还是相当高的，不仅仅对技术，而且对运维都有很高的要求，我们需要设计出一款简单易用的轻量级微服务架构来满足自身的需求，下面用一张图来描述一下我们对微服务架构的愿景。1.4.1 微服务架构图
微服务架构图如图1-5所示。图1-5 微服务架构图
我们不妨从下往上来理解这张图。底层部署了一系列的Service，每个Service可能有自己的DB，或者多个Service公用一个DB，且同一个Service可部署多个。当Service启动时，会自动将其信息注册到Service Registry（服务注册表）中，比如：每个服务的IP与端口。当Web UI上发出请求时，该请求会发送到Service Gateway（服务网关）中，Service Gateway读取请求数据，并从Service Registry中获取对应Service的信息（IP与端口），最后Service Gateway主动去调用下面对应的Service。整个过程就是这样，其中Service Registry与Service Gateway担当了重要的角色。
可能大家会认为Service Gateway将成为一个中心，会造成单点故障。没错，完全有这个可能，所以我们需要将它做得越“薄”越好，所以我们在技术选型上，需要谨慎考虑。
此外，对于Service Registry的高可用性也有很高的要求，它不仅需要在每个Service启动时提供“服务注册”，还需要在Service Gateway处理每个请求时提供“服务发现”。如果它失效了，整个系统将无法工作。
看来搭建微服务架构确实需要在技术选型上做一些考究，需要找到最适合的“演员”把这场“戏”演好。1.4.2 微服务技术选型
我们可使用Spring Boot作为微服务开发框架，Spring Boot拥有嵌入式Tomcat，可直接运行一个jar包来发布微服务，此外它还提供了一系列“开箱即用”的插件，可大大提高我们的开发效率，我们也可以去扩展更多的插件。
在发布微服务时，可连接ZooKeeper来注册微服务，实现“服务注册”。实际上ZooKeeper中有一个名为ZNode的内存树状模型，树上的节点用于存放微服务的配置信息。使用Node.js处理浏览器发送的请求，在Node.js中连接ZooKeeper，发现服务配置，实现“服务发现”，有大量的Node.js的ZooKeeper客户端可以完成这个任务。
通过Node.js将请求转发到Tomcat上，实现“反向代理”，同样也有大量的Node.js库可供我们自由选择。Node.js的“单线程模型”且“非阻塞异步式I/O”特性，通过“事件循环”的方式来支撑大量的高并发请求，此外Node.js原生也提供了集群特性，可确保高可用性。
为了实现微服务自动化部署，我们可通过Jenkins搭建自动化部署系统，并使用Docker将服务进行容器化封装。
综上所述，微服务架构技术选型如下所示。
Spring Boot：http://projects.spring.io/spring-boot/。
ZooKeeper：http://zookeeper.apache.org/。
Node.js：https://nodejs.org/。
Jenkins：https://jenkins.io/。
Docker：https://www.docker.com/。
我们不妨通过一张关系图来归纳一下微服务架构技术选型，如图1-6所示。图1-6 微服务架构技术选型
①使用Jenkins部署服务。
②使用Spring Boot开发服务
③使用Docker封装服务。
④使用ZooKeeper注册服务。
⑤使用Node.js调用服务。
除了以上的技术选型以外，实际上还有其他可选择的方案，比如Netflix公司开源的微服务技术栈。 Netflix：http://netflix.github.io/。
Spring官方在Spring Boot的基础上，封装了Netflix相关组件，提供了一个名为Spring Cloud的开源项目。 Spring Cloud：http://projects.spring.io/spring-cloud/。
就连曾经的JBoss也推出了自己的微服务框架WildFly Swarm。 WildFly Swarm：http://wildfly-swarm.io/。
当然，JavaEE官方也提供了自己的微服务框架KumuluzEE。 KumuluzEE：https://ee.kumuluz.com/。
此外，还有一个轻量级REST框架也宣称可具备开发微服务的能力。 @Dropwizad: https://www.dropwizad.io/。
以上仅为Java相关的微服务技术选型，其他开发语言也有自己的微服务技术栈。
微服务的春天正向我们走来，大家准备好了吗？1.5 本章小结
本章从传统应用架构所产生的种种问题开始，讲到微服务架构的由来与概念，以及微服务架构的特点与挑战。我们提出了一种轻量级微服务架构设计，以及实现该架构的开源项目，此外还有其他开源组织提供的微服务架构技术选型。我们坚信微服务将会成为新一代SOA的解决方案，并伴随着容器技术一起改变计算机软件行业的未来！
下一章我们将从开发一个简单的服务开始，逐步让大家熟悉微服务的相关技术，最终我们一同将这款轻量级微服务架构实现真正落地。
试读结束[说明：试读内容隐藏了图片]