1.2 关于微服务
1.2.1 什么是微服务
ThoughtWorks 公司的首席科学家 Martin Fowler说 ：
简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
James Lewis 和 Martin Fowler说：
简言之，Microservices 架构风格就像是把小的服务开发成单一应用的形式， 运行在其自己的进程中，并采用轻量级的机制进行通信（一般是 HTTP 资源 API）。这些服务都是围绕业务能力来构建，通过全自动部署工具来实现独立部署。这些服务，其可以使用不同的编程语言和不同的数据存储技术，并保持最小化集中管理。
1.2.2 微服务的特点
- 独立部署，灵活扩展：传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件为单位进行部署。
- 资源的有效隔离：每个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成，有效避免了服务之间争用数据库和缓存资源所带来的问题。
- 按业务组织团队：微服务的设计思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，而微服务的设计思想对团队的划分有着一定影响，使团队组织的划分更倾向于垂直架构。当然，垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分的这么绝对。
1.2.3 微服务的优缺点
优点：
- 每个服务足够内聚，足够小，代码容易理解、开发效率提高。
- 微服务能够被小团队单独开发。
- 微服务是松耦合的，是有功能意义的服务，无论在开发阶段或部署阶段都是独立的；
- 每个服务可以各自进行扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上。
- 容错性提高，一个服务的内存泄露并不会让整个系统瘫痪。
- 微服务能使用不同的语言开发，并且系统不会被长期限制在某个技术栈上。
缺点：
- 微服务把原有的项目拆成多个独立工程，增加了开发和测试的复杂度。
- 微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战。
- 当服务数量增加，管理复杂性增加。
1.2.4 微服务常见组件
微服务虽然带来了架构上的优势，但同时也引入了复杂性，我们需要使用一些组件来解决技术复杂性提高之后带来的问题：
服务注册中心：每个服务实例在启动时，需要想注册中心注册自己的IP地址等信息。服务在调用别的服务接口时，就可以通过注册中心，查询到其他服务的实例，向实例发起请求。
负载均衡：由于服务可以有多个实例，所以不管是来自外部客户端的请求，还是微服务系统内部服务之间发起的请求，都需要引入负载均衡的机制，来发挥多实例集群的作用。负载均衡有两种：服务器端负载均衡和客户端负载均衡，各自具有代表性意义的实现分别是Nginx和Ribbon。
服务网关：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。根据公司流量规模的大小网关可以是一个，也可以是多个。
配置中心：将本地化的配置信息（Properties、XML、YAML等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。配置部分可以单独使用高可用的分布式配置中心，确保一个配置服务出现问题时，其他服务也能够提供配置服务。
API 管理：以方便的形式编写及更新API文档，并以方便的形式供调用者查看和测试。通常需要加入版本控制的概念，以确保服务的不同版本在升级过程中都能够提供服务。
集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
分布式事务：对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务）保证数据的一致性。根据业务的不同，适当地牺牲一些数据的一致性要求，确保数据的最终一致性。
调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。同时统计各个服务的调用次数，确保比较热的服务能够被分配更多的资源。
支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么就需要将大部分的工作自动化。这时，需要合适的支撑平台或工具来中和这些微服务架构带来的弊端。
1.2.5 Spring Cloud 与微服务架构
Spring Cloud 由 Spring 官方开发维护，基于 Spring Boot 开发，提供了一整套完整的微服务解决方案。Spring Cloud 的技术选型是中立的，目前大多数的组件都来源于 Netflix 公司的开源产品，包括服务中心 Eureka ，服务网关 Zuul 、负载均衡组件 Ribbon 等等。并且这些组件都可以随需扩展和替换。
在早些年，国内互联网公司盛行采用阿里巴巴公司在 Github 开源的 Dubbo 组件来架构系统应用。但是，Dubbo 在未来的定位并不是要成为一个微服务的整体解决方案，而是专注于 RPC 领域，成为微服务一个重要的组件。以致于微服务衍生出的服务治理的需求，阿里巴巴再次启动开源项目予以支持，比如最近宣布开源的 Spring Cloud Alibaba ，其中 Dubbo 可以做为组件使用 Nacos 作为服务中心整合进入 Spring Cloud 的生态。
从技术选型的角度上来讲，两相比较， Dubbo 和 Spring Cloud ，如果只是图方便和快捷，完全可以使用 Spring Cloud 全家桶来构建微服务，但是， Spring Cloud 服务之间的调用是通过 RESTful 来进行通信，这种调用协议从效率上讲是比较低下的，当然， Dubbo 服务之间的调用是通过 RPC 来进行的，相比较 RESTful 这种形式，性能肯定会超出很多，但是 Dubbo 的生态却又有些令人担心，如果其余的技术栈都需要重新选型，那么无疑将耗费大量的人力。不过无需担心，前段时间刚刚从 Apache 毕业的 Spring Cloud Alibaba 开源项目已经为我们完美的解决了这个问题，其中的一个组件 Dubbo Spring Cloud 就是为了使 Dubbo 无缝接入 Spring Cloud 。
