分析解剖微服务系列（一）-什么是微服务

　　　　微服务架构，是以专注单一责任的小型功能模块为基础、通过API集相互通讯的方式完成复杂业务系统搭建的一种设计思想

一、架构趋势图

软件发展的不同时期、阶段，对技术的理解、选择和应用都有着不一样的诉求。架构的选型，永远只有“合适与不合适”，永远没有“哪个更好”的说法。我们今天来谈论微服务，并不是因为它更牛，而是经过谨慎分析，认为微服务的思想更符合我们的目标。

二、微服务的故事

很久以前的一天，Martin 在跟好友的交流中悟到了一种很棒的架构设计。他总结了一下，然后告诉了好友，好友说，这不是新鲜东西，早有人总结了，叫做 SOA。

Martin 很高兴，开始在公司内外推广 SOA。结果，不停有人质疑和挑战他。

你这不是 SOA 吧？SOA 这里应该是如此这般的。对，这里我对 SOA 的理解是这样的。你看，这本 SOA 的书说的和你说的有出入。粒度？SOA 没有谈到这个呀，你这不是 SOA。分层跟 SOA 没有关系，你为什么要说这个呢？…

Martin 没办法，心一横，老子就叫它 Martin's SOA。老子发明的词，老子就是最高权威，有最终解释权。还有谁不服？

同事们一看，这思想本身很不错，值得推广，但叫 Martin's SOA 太没品了吧？还是要取个好一点的名字，最好还能跟 SOA 有某种暗示传承。干脆就叫 Microservices 好了，又新，又有服务含在其中。

Martin 忿忿地接受了这个建议，心里想着：妈的，明明就是 SOA，一群傻逼非要逼我取个新名字。

后来 Martin 发现每次提一个东西就会收到旧恶傻势力对解释权的挑战，所以每次要提一个什么概念，都去发明一个新词，免得一群人在那一边质疑挑战，一边大谈“我的理解”。

这就是微服务、敏捷、精益企业、持续集成、持续交付背后的故事。

一个名词产生之后，命名者的解释权就会随着时间而弱化（比如 Cooper 发明的 Persona 就被无数设计师乱用）。敏捷已经有点烂了，等微服务也烂了，我们还会发明新词。

三、什么是微服务

微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”。文中内容提到：微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

四、微服务的优势

1、复杂度可控

在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。

由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

2、独立部署

由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。

由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

3、技术选型灵活

微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。

由于每个微服务相对简单，所以需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。

4、容错

当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。

在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

5、扩展

单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

五、微服务的核心理念

从五个具体的方面来谈：

业务拆分，体现在设计环节：在设计的时候，要有足够的判断力来合理的规划服务之间的界限。

服务治理，底层技术的支持：首先要选一款适合自己实际情况的分布式服务基础框架，对于服务的发现、治理、熔断、降级，都要做好相应的技术准备。

自动测试，一定要自动化。微服务一个明显的表象就是随着服务的增多，如果继续沿用传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到更多的环节实现自动化。

自动运维 ：微服务拆分之后，每个服务都可以独立部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。

监控：包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话：没准备好监控，就不要搞微服务。