微服务架构学习（一）：什么是微服务

前言

目前处于新型冠状病毒疫情的爆发期，已经自觉在家隔离5天了，还需在家隔离一周多的时间，因此趁着这段闲暇时光，我决定学习一下微服务架构。为什么呢？因为目前参与的一个项目，经过了两年多的开发周期，迭代了无数版本，代码量惊人，功能繁多冗杂，已经发展到了一定体量，目前慢慢浮现了越来越多的问题，不得不引起我们项目组所有成员的注意，例如新人熟悉项目培养慢，代码功能耦合度高且存在大量冗余，修改一个小bug需重新打包部署整个项目，有性能瓶颈等。

什么是系统架构设计

想要学习理解什么是微服务架构，那么提前先简单理解什么是系统架构设计。系统架构设计描述了在应用系统的内部，如何根据业务、技术、组织、灵活性、可扩展性以及可维护性等多种因素，将应用系统划分成不同的部分，并使这些部分彼此之间相互分工、相互协作，从而为用户提供某种特定的价值的方式。

单体应用

理解了系统架构设计，我们再说单体应用，通常跟微服务相对的就是单体应用，我们目前的项目就是单体应用，即将所有功能都打包成在一个独立单元的应用程序。正是因为目前单体应用的三层架构存在很多弊端，不满足业务发展的需求了，所以才会考虑向微服务架构改造。

三层架构的具体内容如下：

• 表示层： 用户使用应用程序时，看到的、听见的、输入的或者交互的部分。
• 业务逻辑层： 根据用户输入的信息，进行逻辑计算或者业务处理的部分。
• 数据访问层： 关注有效地操作原始数据的部分，如将数据存储到存储介质（如数据库、文件系统）及从存储介质中读取数据等。

虽然现在程序被分成了三层，但只是逻辑上的分层，并不是物理上的分层。也就是说，对不同层的代码而言，经过编译、打包和部署后，所有的代码最终还是运行在同一个进程中。而这，就是所谓的单块架构。

总结一下单体应用的优缺点：

优点：

• 易于开发： 开发方式简单，IDE 支持好，方便运行和调试。
• 易于测试： 所有功能运行在一个进程中，一旦进程启动，便可以进行系统测试。
• 易于部署： 只需要将打好的一个软件包发布到服务器即可。
• 易于水平伸缩： 只需要创建一个服务器节点，配置好运行时环境，再将软件包发布到新服务器节点即可运行程序（当然也需要采取分发策略保证请求能有效地分发到新节点）。

缺点：

• 维护成本大： 当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加。当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug。
• 持续交付周期长： 构建和部署时间会随着功能的增多而增加，任何细微的修改都会触发部署流水线。
• 新人培养周期长： 新成员了解背景、熟悉业务和配置环境的时间越来越长。
• 技术选型成本高： 单块架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大。
• 可扩展性差： 随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展。

在总结了单体组件的优缺点后，也就明白了，为什么我们要学习微服务架构。虽然说微服务架构也不是完完全全可以将所有问题都解决，也并非微服务架构就没有缺点，只是在应用服务发展到一定的阶段时，微服务架构可以解决很大一部分问题，它是一个衍生架构，都是从单体架构演化而来的。因为微服务架构本身的复杂性，初创系统出于快速开发、快速验证的考虑，很少在一开始就使用微服务架构。加之微服务的概念在这两年才火，大型单体应用也是看到了开发与维护的成本在不断增加，才会有转型微服务的动力。因此，如何从单体到微服务是一个普遍问题，并不是一蹴而就的，这是一个逐渐演变的过程。

微服务架构

先从百度上了解一下什么是微服务架构。微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

从描述上来看，给人一种看得懂，但不理解的感受。因此我们继续剖析微服务的特性。

1. 单一职责
   微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。

2. 轻量级通信
   服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式。

3. 独立性
   每个服务在应用交付过程中，独立地开发、测试和部署。
   
   在单块架构中所有功能都在同一个代码库，功能的开发不具有独立性；当不同小组完成多个功能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用被构建成一个包，如果某个功能存在 bug，将导致整个部署失败或者回滚。
   
   在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。

4. 进程隔离
   单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署。
   在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上。

再继续总结一下微服务的本质：

1. 服务作为组件
   微服务也可以被认为是一种组件，但是跟传统组件的区别在于它可以独立部署，因此它的一个显著的优势。另外一个优点是，它在组件与组件之间定义了清晰的、语言无关、平台无关的规范接口，耦合度低，灵活性非常高。但它的不足之处是，分布式调用严重依赖于网络的可靠性和稳定性。
2. 围绕业务组织团队
   在单块架构中，企业一般会根据技能划分团队，在这种组织架构下，即便是简单的需求变更都有可能需要跨团队协作，沟通成本很高。而在微服务架构中，它提倡以业务为核心，按照业务能力来组织团队，团队中的成员具有多样性的技能。
3. 关注产品而非项目
   在单块架构中，应用基本上是基于“项目模式”构建的，即项目启动时从不同技能资源池中抽取相关资源组成团队，项目结束后释放所有资源。这种情况下团队成员缺乏主人翁意识和产品成就感。
   在微服务架构中，提倡采用“产品模式”构建，即更倾向于让团队负责整个服务的生命周期，以便提供更优质的服务。
4. 技术多样性
   微服务架构中，提倡针对不同的业务特征选择合适的技术方案，有针对性的解决具体业务问题，而不是像单块架构中采用统一的平台或技术来解决所有问题。
5. 业务数据独立
   微服务架构提供自主管理其相关的业务数据，这样可以随着业务的发展提供数据接口集成，而不是以数据库的方式同其他服务集成。另外，随着业务的发展，可以方便地选择更合的工具管理或者迁移业务数据。
6. 基础设施自动化
   在微服务架构的实践过程中，对持续交付和部署流水线的要求很高，将促进企业不断寻找更高效的方式完成基础设施的自动化及 DevOps 运维能力的提升。

总结

大体了解过一遍后，心中对微服务架构有了一定的理论知识基础，下次继续学习对比分析一下单体应用和微服务应用的优缺点，以及我的项目，为什么要做微服务的改造。