微服务发展的历史_1 WHY-为什么需要微服务

1.1 传统的单体应用的问题

说到传统的单体应用，它有着悠久的历史，从Web应用发展的早期一直到今天都要非常多的应用。单体架构无疑是一个成功的架构设计，当你只想做一个小的应用或者Web服务时，它是一个最优的选择，但是历史的车轮走到今天，互联网的体量已经是早期的成千上万倍，这时候如果想用单体架构去服务上千万甚至上亿的用户这显然是极度困难的。

单体架构在现有的互联网环境下的缺陷：

1. 难以横向扩展（伸缩性差），无法根据需要单独提升系统中某一模块的性能。
2. 系统内部错综复杂难以维护。
3. 交付效率低，必须以大版本的形式统一交付。
4. 可靠性差，一小块代码的错误可能导致整个系统宕机。
5. 无法升级现有技术，系统中牵一发而动全身。
   当然单体应用也是有它对应的优点，比如易于开发、易于测试、易于部署，但是它的缺点更加的显而易见和不可协调。

1.2 什么是微服务

这里先引用wiki上的一段定义：

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

上述的描述其实已经很好的表述了微服务的精髓，用多个单一责任或功能的独立系统通过API互相通信，最终构建为一个统一的大型系统。

最早这个概念是由Peter Rodgers博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，然后由Martin Fowler与James Lewis于2014年共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。

对于单体系统来说微服务系统的开始可能会更复杂，因为它需要开发人员或者架构师先对业务进行合理细致的划分才可以进行开发，并且在开发过程中会有更多的技术问题，所以相对应的也提高了对开发人员技术水平的要求。

1.3 微服务相对单体架构的优势

在1.1章节已经列举了单体系统在现有互联网环境下的缺点，也在1.2章节中阐述了什么是微服务，大家应该已经对两者有了大致的概念与想法，所以微服务的优势我们就可以总结如下：

1. 可维护性高，每个小组或者开发只需要深入理解自己所负责的模块。
2. 易于部署，每个服务可以单独进行发布，不会影响整体服务。
3. 易于横向扩展，可以根据需要单独提升系统中某一模块的性能。
4. 交付速度快，可维护性高和易于部署解决了交付困难的问题。
5. 技术升级简单，每个模块可以单独升级框架或语言，互不影响。
6. 可靠性高，单个服务出现问题不会导致整体系统宕机。
   以上的优势都是在现代软件开发过程中必不可少的需求，应对互联网现在越来越快的发展速度，小步快跑（减少每次迭代功能、增加迭代次数、减少试错成本）必然成为未来的发展方向，所以采用微服务重构单体架构势在必行。

1.4 最终的目标

我们的最终目标是实现一个可维护性高、交付速度快、可靠性高、技术升级简单的系统。

对于开发人员，每个需求的变更与新增大概率只影响到为数不多的模块，所以在开发时可以更加容易的理解业务的上下文和评估代码更改的影响范围，减少开发人员的心智负担。

对于测试人员，因为代码更改只影响到为数不多的模块，所以可以很容易的评估出需求影响的范围，并采用自动化测试对影响范围内的接口进行回归或验证测试。减少影响范围可以用更少的时间完成测试并且对于风险的把控会更全面。

对于运维人员，只需要部署有变更的几个模块，不影响整体系统的可用性，大大降低了系统部署的风险。

最后我们会得到一个小步快跑的开发流程：

1. 产品提出需求。
2. TeamLeader或开发进行需求拆分，拆解到模块级别。
3. 将拆解后的需求分配到对应开发。
4. 各个开发并行完成：
   1. 代码编写
   2. 单元测试
   3. 冒烟测试
   4. 提交变更至测试
   5. 发布上线
5. 所有相关开发完成上线，该需求上线完成。
   以上步骤配合完善的自动化测试和发布流程，可以做到相对于传统瀑布式开发更偏向于敏捷开发的流程，提高了技术部门的交付效率并且降低了新需求对现有功能的影响风险。其中完善的自动化测试和发布流程是重中之重，做到极致时，甚至可以做到小时级的产品交付，这也是我们努力的方向。