微服务概念

目录

• 为何须要微服务架构
• 什么是微服务
• 微服务架构和单体架构的比较
• 微服务架构和SOA的比较
• 微服务要点
• 第一代微服务框架
• 服务网格
• 参考

为何须要微服务架构

传统IT架构面临的一些问题：
对于企业：

• 使用传统的单体应用架构开发系统，如CRM、ERP等大型应用，且须要不断演变。随着新需求的不断增长，更新和维护会变得愈来愈困难。
• 随着移动互联网的发展，企业被迫将其应用迁移至现代化UI界面架构以便能兼容移动设备，这要求企业能实现应用功能的快速上线。
• 随着应用云化的日益普及，生于云端的应用具备与传统IT不一样的技术基因和开发运维模式。
• 许多企业在SOA投资中获得的回报有限，SOA能够经过标准化服务接口实现能力的重用，但对于快速变化的需求，受到总体式应用的限制，有时候显得力不从心；

对于产品：

• 不少时候，客户须要的不是一个大而全的平台，他们但愿按他们的意愿采购须要的模块。
• 其它研发团队或以前项目有一些比较好的组件能知足平台产品的需求，却不能直接拿来用。

此外，从技术方面看，云计算及互联网公司大量开源轻量级技术不停涌现并日渐成熟：

• 互联网/内联网/网络更加成熟；
• 轻量级运行时技术的出现(node.js, WAS Liberty等)；
• 新的方法与工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；
• 新的轻量级协议(RESTful API接口, 轻量级消息机制)；
• 简化的基础设施：操做系统虚拟化(hypervisors), 容器化(e.g. Docker), 基础设施即服务 (IaaS), - 工做负载虚拟化(Kubernetes,Spark…)等；
• 服务平台化(PaaS)： 云服务平台上具备自动缩放、工做负载管理、SLA 管理、消息机制、缓存、构建管理等各类按需使用的服务；
• 新的可替代数据持久化模型：如NoSQL, MapReduce, BASE, CQRS等；
• 标准化代码管理：如Github等。

这一切都催生了新的架构设计风格 – 微服务架构的出现。

什么是微服务

参考2014年3月Martin Fowler关于微服务架构的文章。微服务架构是一种架构模式，它提倡将单一应用程序划分红一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每一个服务运行在其独立的进程中，服务与服务间采用轻量级的通讯机制互相协做（一般是基于HTTP协议的Restful API）。每一个服务都围绕着具体业务进行构建，并使用自动化布署工具进行独立的发布。能够有一个很是轻量级的集中式管理来协调这些服务，可使用不一样的语言来编写服务，也可使用不一样的数据存储。

In short, the microservice architectural style [1] 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.

微服务架构 ≈ 模块化开发 + 分布式计算

通用特性:

• 经过服务实现应用的组件化
• 围绕业务能力组织服务 每一个微服务仅关注于完成一件任务并很好地完成该任务。每一个任务表明着一个小的业务能力。 因相同缘由而变化的功能聚合到一块儿，而把因不一样缘由而变化的功能分离开
• 智能端点与管道扁平化
• 去中心化 使用合适的工具完成各自的任务
• 基础设施自动化

微服务架构和单体架构的比较

架构	优势	缺点	适用场景
单体应用	1. 开发简单直接，集中式管理 2. 功能都在本地，没有分布式的管理开销和调用开销	1. 随着项目增大，会带来开发效率低，代码维护难，部署不灵活的问题 2. 扩展性不足（横向的硬件资源扩展和纵向的功能扩展）	小项目，临时项目
微服务	1. 下降系统复杂度。单体应用分解为一组服务，每一个服务都比较简单，只关注于一个业务功能 2. 松耦合，服务可独立开发 3. 跨语言，选择合适的语言和技术，而且易于重构和升级 4. 服务可独立部署，使得持续集成和部署成为可能也是必须 5. 服务可独立扩展，根据服务特性选择硬件资源 6. 和 Docker 容器结合的更好	1. 分布式使服务间的调用，通讯，跟踪变的复杂 2. 分区的数据库体系和分布式事务 3. 服务数量多，系统碎片化。必须考虑到部署，管理问题 4. 跨多个服务的更改须要仔细规划和协调	大且业务复杂度高的项目， 须要长期演进的项目

微服务架构和SOA的比较

架构	相同点	差别点
SOA	以服务为核心	SOA更关注企业规模范围，强调的是异构系统之间的通讯和解耦合。 重ESB 以Web Service/BMP/ESB等技术为主
微服务	以服务为核心	微服务架构则更关注应用规模范围，强调的是系统按业务边界作细粒度的拆分和部署。 微服务甚至是去ESB、去中心化、分布式 采用许多新的开源技术和经验

微服务要点

• 配置管理：将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差异性，方便程序包的迁移。
• 服务注册发现：服务提供方将本身调用地址注册到服务注册中心，让服务调用方可以方便地找到本身。服务调用方从服务注册中心找到本身须要调用的服务的地址。
• 负载均衡：服务提供方通常以多实例的形式提供服务，负载均衡功能可以让服务调用方链接到合适的服务节点。
• API 网关：服务网关是服务调用的惟一入口，能够在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
• 服务安全
• 集中日志
• 集中监控
• 分布式跟踪
• 服务容错
• 服务扩展和健康检查
• 服务发布部署

第一代微服务框架

• Spring Cloud
  Spring Cloud为开发者提供了快速构建分布式系统的通用模型的工具
• Dubbo
  Dubbo是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

可是显而易见，不管是Dubbo仍是Spring Cloud都只适用于特定的应用场景和开发环境，它们的设计目的并非为了支持通用性和多语言性。而且它们只是Dev层的框架，缺乏DevOps的总体解决方案（这正是微服务架构须要关注的）。

服务网格

2017 年末，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。译做“服务网格”，做为服务间通讯的基础设施层。能够将它比做是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。

Service Mesh有以下几个特色：

• 应用程序间通信的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

目前流行的Service Mesh开源软件有Linkerd，Envoy，Istio，Conduit等。

• Linkerd：第一代 Service Mesh，2016 年 1 月 15 日首发布，业界第一个 Service Mesh 项目，由 Buoyant 创业小公司开发（前 Twitter 工程师），2017 年 7 月 11 日，宣布和 Istio 集成，成为 Istio 的数据面板。
• Envoy：第一代 Service Mesh，2016 年 9 月 13 日首发布，由 Matt Klein 我的开发（Lyft 工程师），以后默默发展，版本较稳定。
• Istio：第二代 Service Mesh，2017 年 5 月 24 日首发布，由 Google、IBM 和 Lyft 联合开发，只支持 Kubernetes 平台，2017 年 11 月 30 日发布 0.3 版本，开始支持非 Kubernetes 平台，以后稳定的开发和发布。
• Conduit：第二代 Service Mesh，2017 年 12 月 5 日首发布，由 Buoyant 公司开发（借鉴 Istio 总体架构，部分进行了优化），对抗 Istio 压力山大，也期待 Buoyant 公司的毅力。

Linkerd和Envoy比较类似，都是一种面向服务通讯的网络代理，都可实现诸如服务发现、请求路由、负载均衡等功能。它们的设计目标就是为了解决服务之间的通讯问题，使得应用对服务通讯无感知，这也是Service Mesh的核心理念。Linkerd和Envoy像是分布式的Sidebar，多个相似Linkerd和Envoy的proxy互相链接，就组成了service mesh。

而Istio则是站在了一个更高的角度，它将Service Mesh分为了Data Plane和Control Plane。Data Plane负责微服务间的全部网络通讯，而Control Plane负责管理Data Plane Proxy。Conduit定位和功能与Istio相似。

参考

• 解析微服务架构
• 理解微服务架构的核心
• Spring Cloud vs. Kubernetes
• 从0开始的微服务架构
• 微服务和服务网格概念整理