WHAT - 什么是微服务

微服务简介

这次参加JavaOne2015最大的困难就是听Microservice相关的session，无论内容多么水，只要题目带microservice，必定报不上名，可见Microservice有多火。最喜欢其中一页。关于这个典故，可以参考this，此图适用于一切高大上的名字——技术有SOA，Agile，CLOUD，DevOps等等，古代有道，气，八卦等等。此类名词的最大特点就是 一解释就懂，一问就不知，一讨论就打架。 

微服务的流行，Martin功不可没，这老头也是个奇人，特别擅长抽象归纳和制造概念，我觉的这就是最牛逼的markting啊，感觉这也是目前国人欠缺的能力。

Martin Fowler是国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家.福勒（Martin Fowler），在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界顶级的专家，现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和集成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几本经典书籍： 《企业应用架构模式》、《UML精粹》和《重构》等。—— 百度百科

先来看看传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（比较难传神的翻译）。所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。

Monolithic比较适合小项目，优点是：

• 开发简单直接，集中式管理

• 基本不会重复开发

• 功能都在本地，没有分布式的管理开销和调用开销

它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断

• 代码维护难：代码功能耦合在一起，新人不知道何从下手

• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长

• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉

• 扩展性不够：无法满足高并发情况下的业务需求

所以，现在主流的设计一般会采用Microservice Architecture，就是基于微服务的架构。简单来说， 微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

用《The art of scalability》一书里提到的scale cube比较容易理解如何拆分。你看，我们叫分库分表，别人总结成了scale cube，这就是抽象的能力啊，把复杂的东西用最简单的概念解释和总结。X轴代表运行多个负载均衡器之后运行的实例，Y轴代表将应用进一步分解为微服务 （分库），数据量大时，还可以用Z轴将服务按数据分区（分表）

微服务的具体特征

先看看最官方的定义吧

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are **built around business capabilities** and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies.
-- James Lewis and Martin Fowler

把Martin老头的定义大概的翻译一下就是下面几条，这个定义还是太抽象是不是，那就对了，就是要务虚，都说明白了谁还找他付费咨询啊，这么贵。
1. 一些列的独立的服务共同组成系统
2. 单独部署，跑在自己的进程里
3. 每个服务为独立的业务开发
4. 分布式的管理

Martin自己也说了，每个人对微服务都可以有自己的理解，不过大概的标准还是有一些的。

• 分布式服务组成的系统

• 按照业务而不是技术来划分组织

• 做有生命的产品而不是项目

• Smart endpoints and dumb pipes（我的理解是强服务个体和弱通信）

• 自动化运维（DevOps）

• 容错

• 快速演化

SOA vs Microservice

除了Smart endpoints and dumb pipes都很容易理解对吗？相信很多人都会问一个问题，这是不是就是SOA换了个概念，挂羊头卖狗肉啊，有说法把Microservice叫成 Lightway SOA。也有很多传统砖家跳出来说Microservice就是SOA。其实Martin也没否认SOA和Microservice的关系。

我个人理解，Microservice是SOA的传承，但一个最本质的区别就在于Smart endpoints and dumb pipes，或者说是真正的分布式的、去中心化的。Smart endpoints and dumb pipes本质就是去ESB，把所有的“思考”逻辑包括路由、消息解析等放在服务内部（Smart endpoints），去掉一个大一统的ESB，服务间轻（dumb pipes）通信，是比SOA更彻底的拆分。

HOW - 怎么具体实践微服务

听上去好像都不错，具体怎么落地啊？这需要回答下面几个问题：

• 客户端如何访问这些服务？

• 服务之间如何通信？

• 这么多服务，怎么找?

• 服务挂了怎么办？

客户端如何访问这些服务？

原来的Monolithic方式开发，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的？后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们 拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无 状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。

所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，他的作用包括

• 提供统一服务入口，让微服务对前台透明

• 聚合后台的服务，节省流量，提升性能

• 提供安全，过滤，流控等API管理功能

我的理解其实这个API Gateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作 用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。

一般用过Taobao Open Platform的就能很容易的体会，TAO就是这个API Gateway。

服务之间如何通信？

因为所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通行就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式。这几种方式，展开来讲都可以写本书，而且大家一般都比较熟悉细节了， 就不展开讲了。

• 同步调用

  • REST（JAX-RS，Spring Boot）

  • RPC（Thrift, Dubbo）

• 异步消息调用(Kafka, Notify, MetaQ)

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要 求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个 的开发规范和统一的服务框架时，他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。

而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能 保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

这么多服务，怎么找?

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互 感知？服务如何管理？这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当 服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法， 找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

• 客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。

• 服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

这么多服务，服务挂了怎么办？

前面提到，Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠 的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。我们刚遇到一个线上故障就是一个很不起眼的SQL计数功能，在访问量上升 时，导致数据库load彪高，影响了所在应用的性能，从而影响所有调用这个应用服务的前台应用。所以当我们的系统是由一系列的服务调用链组成的时候，我们 必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

• 重试机制

• 限流

• 熔断机制

• 负载均衡

• 降级（本地缓存）

这些方法基本上都很明确通用，就不详细说明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

WHY - 微服务的应用

这里有一个图非常好的总结微服务架构需要考虑的问题，包括

• API Gateway

• 服务间调用

• 服务发现

• 服务容错

• 服务部署

• 数据调用

微服务的优点和缺点（或者说挑战）一样明显。

• 优点

  • 开发简单

  • 技术栈灵活

  • 服务独立无依赖

  • 独立按需扩展

  • 可用性高

• 缺点（挑战）

  • 多服务运维难度

  • 系统部署依赖

  • 服务间通信成本

  • 数据一致性

  • 系统集成测试

  • 重复工作

  • 性能监控

没有最好的，只有适合自己的。

• 对于大的互联网公司，微服务架构是血液，是习惯，每家公司都有自己的套路和架构，细节有不同，但是核心理念是通的。

• 对于一般的公司而言，实践微服务有非常大的技术挑战，于是乎才有了这么多IT供应商考虑这里的商机。微服务比较适合未来有一定的扩展复杂度，且有 很大用户增量预期的应用，说人话就是新兴的互联网公司。创业初期，不可能买大量的机器或者很贵的机器，但是又必须考虑应对成功后的巨量的用户，微服务架构 成了最好的选择。 

So What - 思考

看到上面的图，不是不觉得特别的熟悉？其实我们N年前就用的滚瓜烂熟了好不好？裤子都拖了，你就给我看这个？

from: https://github.com/Netflix/recipes-rss/wiki/Architecture

其实本来所谓的微服务就是对互联网在应用技术的一个总结归纳，IT厂商鼓吹所有概念无非是为了生意（business），SOA是，Cloud是，Microservice也是。下面玩笑很有意思的概括了这个情况（我加了第一条线，原图见这里）

所以微服对我们的思考我觉得更多的是思维上的，对已微服务架构， 技术上不是问题，意识比工具重要。

• 按照业务 或者客户需求组织资源（这是最难的）

• 做有生命的产品，而不是项目

• 头狼战队，全栈化

• 后台服务贯彻Single Responsibility Principle

• VM->Docker （to PE）

• DevOps (to PE)

同时，对于开发同学，有这么多的中间件和强大的PE支持固然是好事，我们也需要深入去了解这些中间件背后的原理，知其然知其所以然，设想下，如果我们是一个小公司的CTO，离开的阿里的大环境，在有限的技术资源如何通过开源技术实施微服务？

最后，一般提到微服务都离不开DevOps和Docker，理解微服务架构是核心，devops和docker是工具，是手段。下次在抽时间再学习整理下。

参考资料和推荐阅读

• http://www.infoq.com/articles/microservices-intro

• http://martinfowler.com/articles/microservices.html

• http://martinfowler.com/microservices/

• http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

• https://www.nginx.com/blog/introduction-to-microservices/

• http://microservices.io/patterns/microservices.html

• http://www.infoq.com/presentations/migration-cloud-native

• https://github.com/Netflix/recipes-rss

• http://www.mattstine.com/microservices

  
  

  一个完整的微服务系统，应该包含哪些功能？

  摘要：近几年，微服务架构迅速在整个技术社区窜红，它被认为是IT软件架构的未来方向，大神Martin Fowler也给微服务极高的评价。

  

  近几年，微服务架构迅速在整个技术社区窜红，它被认为是IT软件架构的未来方向，大神Martin Fowler也给微服务极高的评价。那为什么我们需要微服务，微服务的真正优势到底是什么，一个完整的微服务系统，应该包含哪些功能，本文作者刘彦夫在软件设计和开发领域有10多年工作经验，他将会从他的角度给出答案。

  对微服务的基本理解

  顾名思义，微服务要从两个方面来理解，一个是“微”，一个是“服务”。体型小到一定程度才能叫“微”，这个程度是什么呢？一个身高1米6，体重90斤的MM，我们说她苗条。微服务也一样，根据亚马逊CEO Bezos给出的有趣定义，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两个批萨就够了，这是就是著名的two pizza team rule。

  具备什么样的能力才能算是“服务”？这个话题很大，我这里按照自己的片面理解总结一下，所谓服务就一定会区别于系统的功能，服务是一个或者一组相对的较小且独立的功能单元，是用户可以感知的功能最小集，比如：购物车，订单，信用卡结算等都可以作为单个服务独立提供。

  这个理解显然不够深刻，为了进一步理解为什么微服务在近两年业界迅速窜红，理解为什么微服务会被认为是IT软件架构的未来方向，就要理解为什么我们需要微服务？它能给企业带来什么价值。传统企业的IT软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。后来有了一个叫SOA的软件架构专门针对这些问题给出了一套解决方案，很多企业也因此将自身IT系统迁移到SOA架构上。

  但是，由于SOA早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终SOA开起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

  依然SOA

  微服务，从本质意义上看，还是SOA架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有Java编写的服务，也可以有Python编写的服务，他们是靠Restful架构风格统一成一个系统的。

  最粗浅的理解就是将微服务之间的交互看作是各种字符串的传递，各种语言都可以很好的处理字符串，所以微服务本身与具体技术实现无关，扩展性强。另一个不同是微服务架构本身很轻，底层也有类似于SOA的总线，不过非常轻薄，现在看到的就两种方式：MQ和HTTP，而HTTP都不能完全等同于总线，而仅仅是个信息通道。

  所以，基于这种简单的的协议规范，无论是兼容老旧系统，还是上线新业务，都可以随着时代的步伐，滚动升级。比如：你去年还在使用.NET技术，今年就可以平滑的过度到Go了，而且系统已有服务不用改动。所以微服务架构，既保护用户已有投资，又很容易向新技术演进。

  微服务水下的冰山

  人月不是银弹，微服务更不是银弹，好像软件微服务化了，软件系统就能够应对各种问题了。其实微服务的水面下藏着巨大的冰山。下面是微服务提供的能力，以及背后需要付出的代价。

  1. 单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。

  2. 单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。

  3. 单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。

  4. 多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。

  5. 微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址，类似于到餐厅吃饭，新菜要写到“菜单”中，以供用户选择。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。

  6. 还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。

  综上所述，微服务关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。

  这些系统性的功能也需要有一些服务来提供，这些服务不会直接呈现给最终用户，也就是微服务系统冰山下面的部分，我们可以简称它为微服务系统的“底座”。所有的微服务都像一个APP，插在这个底座的上面，享受这个底座提供的系统能力比如：元数据存放、灰度发布、蓝绿部署等等。

  微服务系统底座

  一个完整的微服务系统，它的底座最少要包含以下功能：

  • 日志和审计，主要是日志的汇总，分类和查询

  • 监控和告警，主要是监控每个服务的状态，必要时产生告警

  • 消息总线，轻量级的MQ或HTTP

  • 注册发现

  • 负载均衡

  • 部署和升级

  • 事件调度机制

  • 资源管理，如：底层的虚拟机，物理机和网络管理

  以下功能不是最小集的一部分，但也属于底座功能：

  • 认证和鉴权

  • 微服务统一代码框架，支持多种编程语言

  • 统一服务构建和打包

  • 统一服务测试

  • 微服务CI/CD流水线

  • 服务依赖关系管理

  • 统一问题跟踪调试框架，俗称调用链

  • 灰度发布

  • 蓝绿部署

  令人困惑的几个问题

  微服务的底座是不是必须的？

  是的，基本上是必须的。你可以不用代码实现一个资源管理服务，可以手工用Excel管理你的所有机器资源，但是不代表微服务系统没有这个功能，只不过这个功能是人工实现的。再举个例子，日志系统如果只是简单的打印文件，那么多个微服务的日志就需要手工收集，人工分类和筛选。所以，微服务的底座最小集一定会存在，问题是看怎样实现它。

  这里仅仅是总结了对微服务系统的基本理解，而实现这个架构有很多技术，这里不进行详细展开。实践方面，推荐王磊的《微服务架构与实践》，他描述了使用Ruby相关的技术实现了一整套微服务系统，特别是书中后面的实践部分讲解了如何将已有的系统演化为微服务架构，是很好的参考和指导材料。

  是不是所有软件都能做微服务？

  这个命题有些微妙，也很难说清楚，回答这个命题本身就是一种挑战，可能最终也没有正确答案。不过，我还是把我自己的理解写在这里，让大家去拍砖。在我这里，答案是否定的。我只需举出一个反例，比如：存储系统，其架构是传统的分层架构，每一层都使用下面一层的服务，并为上一层提供服务。虽然可以将这种架构调整为基于服务的架构，但没办法做成微服务。

  区别在哪里呢？核心的区别在于独立性上，微服务大多是可以独立的运行和使用的，而存储这种非常底层和基础的系统，每层部件都不能单独被使用，比如：Pool管理、CHUNK管理、VOL管理、NFS文件系统，这些功能都无法离开另外一些功能而独立运行，要对外提供可用的存储功能，一大堆功能必须一起上。这种系统做到极致，最多也就能够使其部件可以独立的部署和升级，俗称打热补丁。

  这也就是为什么这种底层传统系统架构通常是单块架构的原因。由于单块架构的各个部分调用关系紧密，做成微服务后系统集成成本会大大增加，不仅如此，这样的架构做成微服务并不能提高交付效率，因为各个部分根本就无法独立的运行和测试。

  什么样的软件做成微服务？

  能不能做成微服务，取决于四个要素：

  • 小：微服务体积小，2 pizza团队。

  • 独：能够独立的部署和运行。

  • 轻：使用轻量级的通信机制和架构。

  • 松：为服务之间是松耦合的。

  针对于小、轻、松都是可以通过某些技术手段达到目的，而独立的部署和运行，则是和业务本身有关系，如果你这个系统提供的业务是贴近最终用户的，并且这些功能之间的耦合性很小，则微服务就可以按照业务功能本身的独立性来划分，则这类系统做成微服务是非常合适的。如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就更加无法做到真正的微服务了。