软件开发并不是一个由定义和执行组成的线性过程，而是一个演化过程，在开发团队真正明白手头的问题之前，需要经历与客户沟通、向客户学习和向客户交付的数次迭代。
使用传统的瀑布方法面临的挑战在于，许多时候，这些项目的交付的软件制品粒度具有以下特点：
- 紧耦合的
- 有漏洞的
- 单体的
基于微服务的构架采用不同的方法来交付功能。具体来说，基于微服务的构架具有以下特点：
- 有约束的——微服务具有范围有限的单一职责集。微服务遵循UNIX的理念，即应用程序是服务的合集，每个服务只做一件事，并只做好一件事
- 松耦合的——基于微服务的应用程序是小型服务的集合，服务之间使用非专属调用协议（如HTTP和REST）通过非特定实现的接口彼此交互
- 抽象的——微服务完全拥有自己的数据结构和数据源。微服务所拥有的的数据只能由该服务修改
- 独立的——微服务应用程序中的每一个微服务可以独立于应用程序中使用的其他服务进行编译和部署
为什么这些微服务构架属性对基于云的开发很重要？基于云的应用程序通常有以下特点：
- 拥有庞大而多样化的用户群
- 极高的运行时间要求
- 不均匀的容量需求
构建一个成功的微服务架构的过程需要结合软件开发组织内多个人的视角。
- 架构师——架构师的工作是看到大局，了解应用程序如何分为单个微服务，以及微服务如何交互以交付解决方案
- 软件开发人员——软件开发人员编写代码并详细了解如何将编程语言和该语言的开发框架用于交付微服务
- DevOps工程师——DevOps工程师不仅为生产环境而且为所有非生产环境提供服务部署和管理的智慧
2.1 架构师的故事：设计微服务架构
架构师在软件项目中的作用是提供待解决问题的工作模型。架构师的工作是提供脚手架，开发人员根据这些脚手架构建他们的代码，使应用程序所有部件都组合在一起。
在构建微服务架构时，关注以下3个关键任务：
（1）分解业务问题
（2）建立服务粒度
（3）定义服务接口
2.1.1 分解业务问题
架构师将业务问题分解成代表离散活动领域的块。这些块封装了与业务域特定部分相关联的业务规则和数据逻辑
分离业务领域是一门艺术，而不是非黑即白的科学：
（1）描述业务问题，并聆听用来描述问题的名词
（2）注意动词。动词突出了动作，通常代表问题域的自然轮廓
（3）寻找数据内聚
2.1.2 建立服务粒度
构建微服务构架时，粒度的问题很重要，可以采取用以下思想来确定正确的解决方案。
（1）开始的时候可以让微服务涉及的范围更广泛一些，然后将其重构到更小的服务
（2）重点关注服务如何相互交互
（3）随着对问题域的理解不断增长，服务的职责将随着时间的推移而改变
Tips:糟糕的微服务的“味道”
如何知道微服务的划分是否正确？如果微服务过于粗粒度，可能会有以下现象：
- 服务承担过多的职责
- 该服务正在跨大量表来管理数据
- 测试用例太多
如果微服务过于细粒度？- 问题域的一部分微服务会像兔子一样繁殖
- 微服务彼此之间严重的互相依赖性
- 微服务成为简单CRUD（Create，Read，Update，Delete）服务的集合
2.1.3 相互交流：定义服务接口
构架师需要关心的最后一部分，是应用程序中的微服务该如何彼此交流。
在设计服务接口时，可以使用以下指导方针思考服务接口设计：
（1）拥抱REST理念——REST对服务的处理方式是将HTTP作为服务的调用协议并使用标准HTTP动词（GET、PUT、POST和DELETE）。
（2）使用URI来传达意图——用作服务端点的URI应描述问题域中的不同资源，并为问题域的资源关系提供一种基本机制
（3）请求和响应使用JSON——JavaScript Object Notation是一个轻量级的数据序列化协议，并且比XML更易于使用
（4）使用HTTP状态码来传达结果
2.2 何时不应该使用微服务
首先，让我们来了解一下构建微服务应用程序的考量因素：
（1）构建分布式系统的复杂性
（2）虚拟服务器/容器散乱
（3）应用程序类型
（4）数据事物和一致性
2.2.1 构建分布式系统的复杂性
因为微服务是分布式和细粒度的，所以它们在应用程序中引入了一层复杂性，而在单体应用程序中就不会出现这样的情况。微服务需要高度的运维成熟度。除非组织愿意投入高分布式应用程序获得成功所需
的自动化和运维工作（监控、伸缩），否则不要考虑使用微服务。
2.2.2 服务器散乱
微服务最常用的部署模式之一就是在一个服务器上部署一个微服务的实例。即使在云中运行这些服务的成本较低，监管和监控这些服务器的操作复杂性也是巨大的。必须对微服务的灵活性与运行所有这些服务器的成本进行权衡。
2.2.3 应用程序的类型
微服务面向可复用性，并且对构建需要高度弹性和可伸缩性的大型应用程序非常有用。但如果构建小型的、部门级的应用程序或具有较小用户群的应用程序，那么搭建一个分布式模型（如微服务）的复杂性可能太昂贵了，不值得。
2.2.4 数据事物和一致性
如果应用程序需要跨多个数据源进行复杂的数据聚合或转换，那么微服务的分布式性质会让这项工作变得很困难。
2.3 开发人员的故事：用Spring Boot 和Java 构建微服务
（1）构建微服务的基本框架并构建应用程序的Maven脚本
（2）实现一个Spring 引导类，它将启动用于微服务的Spring容器，并启动类的所有初始化工作
（3）实现映射端点的Spring Boot 控制器类，以公开服务的端点
2.4 DevOps 工程师的故事：构建运行时的严谨性
（1）服务装配
（2）服务引导
（3）服务注册/发现
（4）服务监控
