微服务笔记

微服务笔记

参考资料：

• 漫画：什么是微服务？
• 微服务架构
• 什么是微服务
• 微服务架构设计

微服务简介

单体架构（Monolithic）的痛点

传统的MVC架构，所有业务子模块都集成在一个很重的JVM进程当中。

所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。

优点：

1. 开发简单，集中式管理，所有代码都在同一个项目当中

2. 基本不会重复开发

3. 功能都在本地，没有分布式的管理和调用消耗

缺点：

1. 开发效率低：开发都在同一个项目改代码，相互等待，冲突不断

2. 代码维护难：代码功功能耦合在一起，新人不知道何从下手

3. 部署不灵活：构建时间长，任何小修改都要重构整个项目，耗时

4. 稳定性差：一个微小的问题，都可能导致整个应用挂掉

5. 扩展性不够：无法满足高并发下的业务需求

6. 资源无法隔离：整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。

7. 无法灵活扩展：当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，部署在多台机器上组成集群。但是这种扩展并非灵活的扩展。比如希望只针对某个功能模块做水平扩展，这一点在单体系统是做不到的。

什么是微服务（Microservice Architecture）？

微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

基于微服务架构的设计目的：有效的拆分应用，实现敏捷开发和部署。

常见的系统架构遵循的三个标准和业务驱动力：

1. 提高敏捷性：及时响应业务需求，促进企业发展

2. 提升用户体验：提升用户体验，减少用户流失

3. 降低成本：降低增加产品、客户或业务方案的成本

微服务的特点

1. 独立部署，灵活扩展。 传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。

用一张经典的图来表现，就是下面这个样子：

图中左边是单体架构的集群，右边是微服务集群。

什么意思呢？比如根据每个服务的吞吐量不同，支付服务需要部署20台机器，用户服务需要部署30台机器，而商品服务只需要部署10台机器。这种灵活部署只有微服务架构才能实现。

而近几年流行的Docker，为微服务架构提供了有效的容器。

2. 资源的有效隔离。 微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。

同时，由于每一个微服务实例在Docker容器上运行，实现了服务器资源（内存、CPU资源等）的有效隔离。

3. 团队组织架构的调整。 微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。

而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。

当然，这种垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分得这么绝对。

微服务架构的不足

微服务把原有的项目拆成多个独立工程