【学习总结】认识微服务

参考连接：

• 漫画：什么是微服务

目录

• 传统的单体架构的痛点
• 单体架构痛点的解决
• 微服务
• 微服务和面向服务架构SOA的区别
• 框架、组件和架构思想
• 微服务架构的不足
  

传统的单体架构的痛点

• 传统的MVC架构，全部业务子模块都集成在一个很重的JVM进程中
  -（MVC：一种设计模式，Model-View-Controller（模型-视图-控制器） 模式。这种模式用于应用程序的分层开发。）
• 单体架构的好处是便于管理，全部代码都在同一个项目中。

缺点：

• 缺点一：项目过于臃肿。

  • 当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。

• 缺点二：资源没法隔离。

  • 就像刚刚小灰的经历同样，整个单体系统的各个功能模块都依赖于一样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。

• 缺点三：没法灵活扩展。

  • 当系统的访问量愈来愈大的时候，单体系统当然能够进行水平扩展，部署在多台机器上组成集群。
    
    可是这种扩展并不是灵活的扩展。好比咱们如今的性能瓶颈是支付模块，但愿只针对支付模块作水平扩展，这一点在单体系统是作不到的。

单体架构痛点的解决

• 臃肿的单体系统拆分红微服务。

微服务

• 微服务（Microservice Architecture）是近几年流行的一种架构思想

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

• 微服务的特色：

  • 1.独立部署，灵活扩展

    • 传统的单体架构是以整个系统为单位进行部署，而微服务则是以每个独立组件（例如用户服务，商品服务）为单位进行部署。
    • 好比根据每一个服务的吞吐量不一样，支付服务须要部署20台机器，用户服务须要部署30台机器，而商品服务只须要部署10台机器。这种灵活部署只有微服务架构才能实现。
    • 而近几年流行的Docker，为微服务架构提供了有效的容器。
      

• 2.资源的有效隔离

  • 微服务设计的原则之一，就是每个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。
  • 同时，因为每个微服务实例在Docker容器上运行，实现了服务器资源（内存、CPU资源等）的有效隔离。
    

• 3.团队组织架构的调整

  • 微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。
  • 而微服务的设计思想对团队的划分有着必定的影响，使得团队组织架构的划分更倾向于垂直架构，好比用户业务是一个团队来负责，支付业务是一个团队来负责。
  • 固然，这种垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分得这么绝对。
    
    

微服务和面向服务架构SOA的区别

• SOA架构强调的是异构系统之间的通讯和解耦合，而微服务架构强调的是系统按业务边界作细粒度的拆分和部署

  
  

框架、组件和架构思想

• Dubbo、Spring Cloud都是框架和组件，而SOA和微服务是架构思想，不是同一个层面的概念。

• 能够说Dubbo和Spring Cloud很好地支持了SOA和微服务架构，但不能说Dubbo是SOA，Spring Cloud是微服务。

微服务架构的不足

• 一、微服务把原有的项目拆分红多个独立工程，增长了开发和测试的复杂度。

• 二、微服务架构须要保证不一样服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来必定的挑战。

• 故：架构设计没有绝对的好与坏，关键看应用场景。

END