微服务是什么

这篇笔记记录了对微服务及其相关概念的学习，作为一个所谓的先导。但是我不认为我能在没有足够实践的情况下就直接理解微服务以及其带来的优势，弊端，直接理解微服务的各种模式（pattern）。总之并行进行嘛。

任何架构，即使是一团糟的架构，基本上都能被用来实现各种业务需求（功能性需求），而问题在于非功能性需求，如可扩展性，可维护性，生产效率，质量管理等。

微服务和与其对应的单体应用其实都是所谓的架构模式，其中单体应用是作为一个整体进行编写和部署的，即使其逻辑上是划分为一个个模块。单体应用在过去基本上是唯一的解决方案，它的优点在于——

• 开发简单：只需要构建一个单独的应用程序。
• 测试直观：开发者只需要编写单元测试，端到端测试，界面测试等便可对系统进行相对完善的测试。
• 部署容易：单独的应用程序，对 Java 来说是 JAR 或 WAR 包，对 Ruby，Nodejs 等语言来说则是一个目录，对其的部署是非常容易的。
• 横向扩展容易：可以运行多个实例，通过一个负载均衡器进行调度。

然而，随着代码规模的增长，技术的发展（同时也意味着旧技术——或许是该项目所使用的技术——的过时！），业务（和模块）的复杂化，这些优点将消失殆尽！

其中最主要的问题是，系统将变得过度复杂，让维护和扩展变成噩梦；同时，开发速度也会变慢，比如，项目的巨大让 IDE 不堪重负，从而编辑——构建——运行——测试这个周期的花费越来越长；多个开发团队向同一个代码库进行提交会导致其最终合并到主分支的过程极为漫长和痛苦；各个模块对硬件要求有自己的独特需要——如负责缓存的模块需要大量内存，负责运算的模块需要大量算力，对单体应用来说，其要使用的服务器需要满足所有模块的要求，这无疑是不够灵活，在进行横向扩展时会造成许多浪费的……

这就是所谓的单体地狱——任何单体应用在无数次迭代后必然导致的结果。而新的解决方案就在眼前——微服务架构。

微服务架构的一个定义是：把应用程序功能性分解为一组服务的架构风格。这里的服务指的并非业务层中的 Service，而是实现了一组相关功能的应用程序。服务是无关规模的！

微服务使用服务作为模块化的单元（原子的），每个服务**通过它提供的 API **构筑了一道绝对无法去逾越的边界（这实际上比编程语言所提供的约定方法更为强大……）。这种架构的优越性是可以直接看到的——各个模块可以独自进行演化——只要提供的 API 不变即可，且各个服务可以独立开发，测试，部署，扩展，甚至可以使用不同编程语言进行编写。这种自由度是单体应用绝对无法提供的。

微服务的优点在于——

• 服务可独立维护，部署，扩展，且由于服务相对较小，对其的维护和测试是容易的。
• 更好的容错性（一个服务实例出现 bug 不会导致整个系统崩溃，故障隔离）。
• 团队协作更加容易且松耦合。
• 让大型复杂应用可以持续交付和持续部署。
• 更容易采取新技术到项目中。

看上去挺香，但是至少在计算机这一行，没有银弹，微服务会造成一些单体应用不会出现的问题和弊端——

• 服务的定义和拆分是一个挑战，其没有一个具体标准，需要丰富的实践经验和理论基础，一旦出错，就可能构造出分布式单体应用，其将不会有任何优势。
• 分布式系统会让整个系统的开发，测试，部署相对困难。具体来说，其会带来更多复杂性——进程间通信而非方法调用、跨服务的事物和查询复杂、需维护数据一致性、IDE 支持问题、运维问题……
• 部署跨服务的功能需要对多个开发团队进行协调，发布需按照计划以满足服务的依赖关系。
• 需思考在什么时候才有必要切换到微服务架构。一般来说项目会从单体应用开始，从微服务架构开始会导致初期进展困难——这是企业不能容忍的。