微服务随想
Intro
在如今微服务的思想和架构流行的今天，以及结合最近在公司实施的微服务化，想谈谈自己对微服务的理解及看法，可能并不太对，如果你觉得哪些有问题，欢迎指出，一起探讨学习。
下面我将从微服务的三个层面去探讨
- 什么是微服务(What)
- 为什么要微服务(Why)
- 微服务化怎么实施(How)
什么是微服务
在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"， 微 狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP REST API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
为什么要微服务
从系统及应用程序的角度来说，起初大部分应用都是单体应用，所有的代码及功能都糅合在一起，随着系统的逐渐变大变得复杂，单体应用的部署和具体的功能模块依赖程，比较严重，相互影响较大，所以到后面通常会引入服务化的概念，将不同的模块拆成不同的服务来进行解耦和降低依赖，提高部署的灵活性。首先被应用的也就是 SOA（Service Oriented Architecture） 架构模式，SOA 架构模式下多有 ESB（Enterprise Service Bus） ，而 ESB 通常与某种语言/某种技术栈是强绑定的，也就决定了 SOA 模式下的开发语言/技术框架选择的限制。之后微服务开始出现在人们的视野之中，微服务的出现使得各个服务之间可以使用不同的技术栈，这对于使用不同语言的技术栈的开发人员来说是一个福音，从整体应用的角度来看，不需要再关注是什么样的语言与技术栈的实现，另外对于大多数互联网应用来说，应用程序的弹性扩展也很重要，微服务化同样使得弹性扩展变得方便简单。
单体应用架构的问题
- 应用各模块耦合严重，复杂性高
- 部署时间长，开发调试体验差效率低
- 应用具体的模块弹性伸缩比较困难
- 系统重构与技术创新困难
SOA 存在的问题
- 抽取的服务的粒度过大，系统与服务之间还有一定程度的耦合
- 对 ESB 比较依赖
- 技术栈相对固定，技术选型受限
微服务的优缺点
- 优点
- 各模块耦合程度低
- 服务自治
- 按需伸缩比较简单
- 技术栈选择不受限，各个服务相互独立
- 发布部署简单，启动速度快
- 缺点
- 运维成本比较高
- 分布式环境复杂
怎么实施微服务
- 微服务整体架构规划，微服务的拆分
- CI/CD 建设
- 系统监控/报警
- Api网关
- 统一的身份认证/授权
- 配置中心
- 分布式调用监控
- 注册中心/服务发现/负载均衡
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]
原文地址：https://www.cnblogs.com/weihanli/p/microservice-overview.html