十分钟了解“微服务”

十分钟了解“微服务”

微服务架构这个概念出来也有3-4年的时间了，从最开始在互联网企业的广泛应用，到现在越来越多的企业开始关注和希望尝试使用微服务架构。那么什么是微服务呢？微服务，又叫微服务架构。微服务架构是一种架构风格，它将一个复杂的应用拆分成多个独立自治的服务，服务与服务间通过松耦合的形式交互。
在认识微服务之前，需要先了解一下与微服务对应的单体式（Monolithic）架构。在Monolithic架构中，系统通常采用分层架构模式，按技术维度对系统进行划分，比如持久化层、业务逻辑层、表示层。 Monolithic架构主要存在以下问题：

1. 系统间通常以API的形式互相访问，耦合紧密导致难以维护；
2. 各业务领域需要采用相同的技术栈，难以快速应用新技术；
3. 对系统的任何修改都必须整个系统一起重新部署或者升级，运维成本高；
4. 在系统负载增加时，难以进行水平扩展；当系统中一处出现问题，会影响整个系统；

为了解决这些问题，微服务架构应运而生。相对于单体架构和SOA，微服务的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

细分为小的服务
服务粒度要小，什么是服务粒度？说白了粗粒度就是大局上看，细粒度就是更关注于细节。具体的话，个人理解就是，粗粒度和细粒度的区别主要是出于重用的目的,比如说类的设计，为尽可能重用,所以采用细粒度的设计模式，将一个复杂的类(这里就是粗粒度)拆分成高度重用的职责清晰的类（这就是细粒度）而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情的服务。

可以独立部署运行
每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。

分配独立的技术团队，实现自治
团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

功能独立开发和演化
技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。

比如下面的示例，将一个系统的后端划分成Account/Inventory/Shipping三个微服务，每个微服务有自己的数据库存储，对外提供风格统一的REST API。

我们可以看到整个微服务的思想就如我们现在面对信息爆炸、知识爆炸是一样的：通过解耦我们所做的事情，分而治之以减少不必要的损耗，使得整个复杂的系统和组织能够快速的应对变化。

总结：微服务在近两年大火，它具备了灵活部署、可扩展、技术异构等优点，但同时也带来了开发、运维的复杂性。是否要采用微服务架构需要根据系统的特点，结合企业的组织架构、团队能力等多个方面进行综合的判断，而不是为了微服务而微服务。
个人建议，在开发一个新的系统时，因为业务逻辑和系统边界还不是那么清晰，可以先采用Monolithic方式开发，直到能够识别出稳定逻辑后再进行微服务的拆分，从而避免因为边界不清而进行重划分所带来的返工。强调：“任何脱离业务逻辑的架构都是耍流氓”。