微服务（Microservice）那点事儿

微服务的兴起

在单体式架构时代，系统里就只有一套代码，一个应用服务了所有的请求。2005年的云计算大会上，Dr. Peter Rogers第一次提出了micro web services的概念，而微服务的崛起，是等到了2011年。互联网时代的崛起，面对指数性增加的请求和横向扩容、快速变更上线等需要，单体式架构无疑无法很好地去服务，而微服务架构开始成为了业界的专注对象。当时最早实验微服务架构的公司，就包括了大型网络公司Netflix和Amazon。

一个微服务架构的系统是一个分布式系统，系统内会由若干个应用组成，每个应用就是一个微服务。根据需求，每个微服务应用可以部署一定数量的服务器，也可以支持横向扩展，随时支持流量的变化。

微服务架构定义

单体式架构中一个个的功能/业务领域都可以成为微服务架构中单一的微服务，而各个微服务可以根据需求横向扩容，不再是单一的1:1的比例。微服务架构中通常会有个统一网关对外提供服务，对内调用都通过底层网络进行，服务之间都有着上下游的关系，随着系统的成长，微服务之间的关系往往会越发复杂。每个微服务都是自己的一套代码，彼此对技术栈没有强一致的需求。

时至今日，我想已经很少有团队把“微服务”的“微”等同于“微小”的“微”了。但当这个技术术语才出来的时候，的确有一定的误导性。我们看到很多人在实践时都对自己的业务系统做了过细的微服务拆分，导致不仅没有享受到微服务带来的便利，反而增加了运维和维护成本。很多人把关注点放在微（micro）上这是不对的，在实践中不管是amazon的two-pizza-team（12个人）维护的一个服务，还是创新公司的一个人一个服务，都可以是微服务。所以，我们先明确一下，微不是指微小，micro是和monolithic相对应的分布式架构风格，和粒度（size）并没有必然的关系。

微服务解决了什么问题

微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

微服务带来了哪些挑战

微服务拆分策略

微服务划分也是分类（即把哪些功能分类到一个服务中）。分类是一门艺术，关键是要找到合适的分类维度。属性越多的事物，越难进行分类。

微服务的划分也是一样，关键是要找到合适的分类维度。我们不妨从微服务的定义看看哪些维度是微服务的关键属性，从而找到合适的划分维度。软件系统最终都是要实现业务价值，一个理想的微服务，应该是能独立完成一个或一组业务能力（业务维度）；一个微服务最好是由一个团队负责，这样不会踩脚（组织维度）；此外，还要满足质量设计要求，比如吞吐量、可靠性、安全性等等（质量维度）。因此，微服务的划分维度，首当其冲的应该是业务功能，其次是组织边界和质量属性。

微服务需要的基础设施

微服务并不是很多人认为的那样又简单又轻量级。要做好微服务，上图中罗列的基础设施都是必不可少的，否则微服务就会变成一个焦油坑，让业务和团队在里面不断挣扎且无法自拔。因此也可以说，微服务并没有减少复杂度，而只是将复杂度从 ESB 转移到了基础设施。可以看到，“服务发现”“服务路由”等其实都是 ESB 的功能，只是在微服务中剥离出来成了独立的基础系统。

虽然建设完善的微服务基础设施是一项庞大的工程，但也不用太过灰心，认为自己团队小或者公司规模不大就不能实施微服务了。第一个原因是已经有开源的微服务基础设施全家桶了，例如大名鼎鼎的Spring Cloud 项目，涵盖了服务发现、服务路由、网关、配置中心等功能；第二个原因是如果微服务的数量并不是很多的话，并不是每个基础设施都是必须的。

通常情况下，建议按照下面优先级来搭建基础设施：

1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施
2. 接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率
3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率
4. 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率

以上3和4这两类基础设施，其重要性会随着微服务节点数量增加而越来越重要，但在微服务节点数量较少的时候，可以通过人工的方式支撑，虽然效率不高，但也基本能够顶住。