系统架构设计之微服务（Microservice）

看了这篇文章总体上会对微服务有个认识，如果不是分布式应用和采用云部署模式，微服务基本上是一个技术概念，如果不能得以实践，姑且听之。

首先来了解一些概念，以下内容来自：http://www.jdon.com/soa/microservice-architecture.html

什么是微服务架构/strong>

　　微服务是指开发一个单个 小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。

　　微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。

微服务优点是什么/strong>

• 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
• 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务能使用不同的语言开发。
• 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。
• 一个团队的新成员能够更快投入生产。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
• 微服务允许你利用融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
• 微服务能够即时被要求扩展。
• 微服务能部署中低端配置的服务器上。
• 易于和第三方集成。
• 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

微服务架构的缺点是什么/strong>

• 微服务架构可能带来过多的操作。
• 需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
• 可能双倍的努力。
• 分布式系统可能复杂难以管理。
• 因为分布部署跟踪问题难。
• 当服务数量增加，管理复杂性增加。

 微服务适合哪种情况/strong>
　　当你需要支持桌面 web 移动 智能电视 可穿戴时都是可以的，甚至将来你可能不知道但需要支持的某种环境。

 哪个公司或产品使用微服务架构/strong>
　　大部分大型网站系统如Twitter, Netflix, Amazon 和 eBay都已经从传统整体型架构monolithic architecture迁移到微服务架构

微服务之间是如何独立通讯的/strong>
　　这依赖需求，通过使用HTTP/REST，数据格式使用JSON 或 Protobuf(Binary protocol)，通讯协议是自由的。

 为什么现在每个人都在谈论微服务/strong>
　　自从SOA面试15年来，随着RESTful web服务和JSON数据交换格式流行，简单快速建立一个可连接的服务已经越来越方便了。

开发方式影响

　　随着持续交付概念推广以及Docker容器普及，微服务将这两种理念和技术结合起来，形成新的微服务+API + 平台的开发模式，提出了容器化微服务的持续交付概念。

　　下图传统Monolithic的DevOps开发队伍方式：

　　微服务促进了DevOps方式的重组，将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍，以及一个大的整体的平台队伍负责运营管理，两者之间通过API交互，做到了松耦合隔绝。

　　由于Docker引入，不同的微服务可以使用不同的技术架构，比如Node.js Java Ruby Python等等，这些单个的服务都可以独立完成交付生命周期，如下：

　　Twitter的微服务架构，注重高效的可扩展的数据中心：

微服务的流行，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等所有逻辑。

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

服务之间如何通信

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

• 同步调用

  • REST（JAX-RS，Spring Boot）

  • RPC（Thrift, Dubbo）

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

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

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

• 重试机制

• 限流

• 熔断机制

• 负载均衡

• 降级（本地缓存）

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

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

• 优点

  • 开发简单

  • 技术栈灵活

  • 服务独立无依赖

  • 独立按需扩展

  • 可用性高

• 缺点（挑战）

  • 多服务运维难度

  • 系统部署依赖

  • 服务间通信成本

  • 数据一致性

  • 系统集成测试

  • 重复工作

  • 性能监控

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

So What – 思考

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

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

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

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

• 头狼战队，全栈化

• 后台服务贯彻Single Responsibility Principle

• VM->Docker （to PE）

• DevOps (to PE)

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

最后，一般提到微服务都离不开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

文章来自阿里巴巴技术协会（ATA）精选集，原文首发于阿里云栖社区：http://yq.aliyun.com/articles/2764 。云栖社区是由阿里云负责运营、阿里巴巴技术协会和阿里巴巴集团各技术团队提供内容支持的开放式技术社区：http://yq.aliyun.com。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8683 人正在系统学习中

来源：boonya