微服务随想

Posted 2020-12-29 weihanli

微服务随想

Intro

在如今微服务的思想和架构流行的今天，以及结合最近在公司实施的微服务化，想谈谈自己对微服务的理解及看法，可能并不太对，如果你觉得哪些有问题，欢迎指出，一起探讨学习。

下面我将从微服务的三个层面去探讨

1. 什么是微服务(What)
2. 为什么要微服务(Why)
3. 微服务化怎么实施(How)

什么是微服务

在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"， 微 狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP REST API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

为什么要微服务

从系统及应用程序的角度来说，起初大部分应用都是单体应用，所有的代码及功能都糅合在一起，随着系统的逐渐变大变得复杂，单体应用的部署和具体的功能模块依赖程，比较严重，相互影响较大，所以到后面通常会引入服务化的概念，将不同的模块拆成不同的服务来进行解耦和降低依赖，提高部署的灵活性。首先被应用的也就是 SOA（Service Oriented Architecture） 架构模式，SOA 架构模式下多有 ESB（Enterprise Service Bus） ，而 ESB 通常与某种语言/某种技术栈是强绑定的，也就决定了 SOA 模式下的开发语言/技术框架选择的限制。之后微服务开始出现在人们的视野之中，微服务的出现使得各个服务之间可以使用不同的技术栈，这对于使用不同语言的技术栈的开发人员来说是一个福音，从整体应用的角度来看，不需要再关注是什么样的语言与技术栈的实现，另外对于大多数互联网应用来说，应用程序的弹性扩展也很重要，微服务化同样使得弹性扩展变得方便简单。

单体应用架构的问题

1. 应用各模块耦合严重，复杂性高
2. 部署时间长，开发调试体验差效率低
3. 应用具体的模块弹性伸缩比较困难
4. 系统重构与技术创新困难

SOA 存在的问题

1. 抽取的服务的粒度过大，系统与服务之间还有一定程度的耦合
2. 对 ESB 比较依赖
3. 技术栈相对固定，技术选型受限

微服务的优缺点

• 优点

  1. 各模块耦合程度低
  2. 服务自治
  3. 按需伸缩比较简单
  4. 技术栈选择不受限，各个服务相互独立
  5. 发布部署简单，启动速度快

• 缺点

  1. 运维成本比较高
  2. 分布式环境复杂

怎么实施微服务

1. 微服务整体架构规划，微服务的拆分
2. CI/CD 建设
3. 系统监控/报警
4. Api网关
5. 统一的身份认证/授权
6. 配置中心
7. 分布式调用监控
8. 注册中心/服务发现/负载均衡

Reference

• https://blog.csdn.net/tiandiwuya/article/details/78543336
• https://blog.csdn.net/wuxiaobingandbob/article/details/78642020?locationNum=1&fps=1
• https://blog.csdn.net/chszs/article/details/78515231
• https://blog.csdn.net/oschina_41740100/article/details/80630901

Contact

后续会展开介绍如果进行具体的实施

Contact me: [email protected]