微服务简单说
- 2019 年 10 月 3 日
- 筆記
1 微服务架构定义
微服务一词源自 马丁·福勒（Martin Fowler) 在2014 年的一篇博客：Microservices 该文章中对微服务定义如下：
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.
微服务架构风格是将单体应用程序 拆分为多个小型的服务 并且每个服务在独立的进程中。服务间的通信采用轻量级通信的机制 通常是HTTP方式提供API 来实现。这些服务通过自动化部署的方式进行独立部署。每个服务可以根据自身的特点采用不同的语言开发同时也可以使用不同的数据存储技术。
服务的拆分是基于业务和公司的组织架构进行拆分，也称之为康威定律。
另外 Adrian Cockcroft 更是将微服务比喻成 细粒度的 SOA（面向服务的架构）
2 单体架构定义
虽然我对微服务的定义进行解释，但是如果想更深层次的了解微服务 我们不得不先从单体架构说起。
单体架构就是 将 web项目应用实例 的所有功能模块打包到一起并放在一个web容器中运行的系统。 例如 我们的一个电商网站 其中包含 商品模块 订单模块 等我们可以通过maven多模块 或者 放入到不同的包中来区分。 但是最终还是将其打包成一个war 部署在我们的tomcate中。
单体架构好处
- IDE友好支持：
NetBeans、Eclipse、IntelliJ 这样工具专门为单体应用设计。 你只需要使用其中一种 就可以在你本地机器上进行 开发 调试 部署。 - 方便测试：
测试人员只需要测试单个应用即可。新开发的功能部署完成就可以测试所有的功能。 - 容易部署：
打包成war包放入我们的服务器 或者打包成一个课执行的jar 执行jar包即可。
单体架构缺点
随着业务规模的发展我们的单体架构会出现如下问题
- 项目越来越复杂（随着业务发展模块会越来越多）
- 项目整体编译耗时长
我们开发人员在进行开发和调试过程中需要化大量的时间在无用的重新编译上。 - 合并代码容易产生冲突
在进行多个需求并行开发时每个分支会涉及到很多相同的代码以至于极易产生冲突。 - 新功能上线周期长
每次进行新功能的开发和bug修改很难预估对项目整体的影响，那就需要进行全部功能的测试。然而这个测试是比较耗时的 导致我们上线时间的延长。 - 项目稳定性差
项目中不重要的功能模块出现bug会导致整个服务瘫痪。 - 只能做横向扩展
由于整个功能模块都在一个实例中，我们对整个服务实例进行扩展，无法针对具体的功能进行垂直的拆分。也无法对某个功能进行单独的硬件升级。 -
不敢做新的技术的尝试
由于我们的项目是单体的架构，项目成员必须使用同一种技术栈进行项目的开发。切换新的技术和语言要对整个项目进行重头开发。这使得尝试新的语言变得比较困难。微服务架构好处
简单点说微服务的好处正式用来弥补单体架构的不足的。具体的好处如下：
- 由于拆分为多个小服务每个服务比较容易理解
- 每个微服务有启动调试速度快，无需过多的等待编译时间
- 我们可以针对每个服务方便进行横向和纵向的扩张
- 根据服务特点 针对性的进行服务器硬件升级
- 单个服务的升级不要其他服务的协调
- 服务拆分和团队组织更匹配
-
尝试新的技术变得更容易
4 微服务架构与SOA的区别
- SOA是面向服务架构。而微服务也是面向服务架构。
- 微服务架构可以理解成更细力度的 SOA。
- 微服务架构强调要采用轻量级的通信。
- 微服务架构强调的是基于业务做细粒度的拆分和部署。
- 微服务构架强调每个服务有独立的数据库。
我的个人理解就是微服务是在SOA 上进一步的延伸而产生的新名词。
5 微服务面临的困难
微服务不是银弹，使用微服务业务也有困难需要解决。当我们将服务拆分多个服务 可能是几十个服务 也有可能是上百甚至上千个服务。这个多服务如何区治理就是我们要面临的困难，具体细分的话包含如下内容：
- 单体系统架构如何拆分
- 多个服务之间的通信
- 服务API文档
- 服务注册发现
- 服务负载均衡
- 服务网关
- 分布式追踪
- 日志聚合
- 集中配置
- 容错限流
- 服务自动化部署
- 监控告警
如果你的项目代码模块 代码逻辑 比较混乱是不能够通过微服务来解决的。引入微服务需要对整个项目的功能进行梳理划分后才能在考虑切换为微服务。
参考文献
和坚 简书博主当我们在说微服务治理的时候究竟在说什么：
Rick Osowski：微服务介绍
承诺一时的华丽 简书博主：Go – Micro微服务框架实践 – 相关概念（六）
每日一拾 简书博主：架构设计漫步：从单体架构、SOA到微服务
