微服务概念

Posted 2020-12-25 royzshare

目录

• 为什么需要微服务架构
• 什么是微服务
• 微服务架构和单体架构的比较
• 微服务架构和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开始的微服务架构
• 微服务和服务网格概念整理