【Express.js】微服务架构

微服务架构

微服务

微服务架构是将一个单体应用程序拆分为一个个独立且保持松耦合的服务的一种架构方式，每个服务有着独立的数据库并且能独立运行部署，所有的服务最终可以被视作一个集群而进行统一管理

优缺点

从微服务的理念着手，它的优缺点绝大部分能通过与单体应用相对比得出

优点

微服务的优点，就是解决了单体应用的痛点

• ★ 高可维护性与高可拓展性
  随着时间的推移，单体项目将不可避免的臃肿无比且交错杂乱，高耦合的屎山代码使得每一次维护与拓展都变得胆战心惊。而微服务将完整系统中的每一个模块抽离出来，使得业务更加清晰且耦合度降低，维护与拓展将会容易很多
• ★ 程序构建与迭代高效
  原本庞大的单体项目修改了源码之后需要整个项目进行重新编译与运行，如果体量足够大，可是要不少时间。拆分为微服务后，只需要重新编译与运行有限的几个微服务即可，由于微服务的体量小很多并且可以并行构建，效率肉眼可见的高
• ★ 系统稳定与健壮性增强
  一体的单体应用中如果某一环出了问题，可能导致整个系统瘫痪的重大事故，而独立且松耦合的微服务系统，完全可以将瘫痪的范围缩小到有限的部分微服务上，而不至于导致整个系统下架维护
• ★ 打破技术限制与瓶颈
  毕竟微服务是独立开来的，因此每个微服务完全可以采取不同的语言与开发环境，以适应各自的特色业务需求，比如需要强劲算力的微服务可以采用Rust语言和更快的GPU硬件，需要图形计算的微服务可以使用Neo4j作为数据库等等

缺点

当然了，微服务也是一把双刃剑，在解决了单体服务的痛点的同时，由于分布式的架构不可避免的带了一些原本不存在的挑战

• 运维与部署成本高
  单体应用不出意外就一个应用程序和一个数据库，运维和部署是很容易的。虽然微服务的每个独立服务可以通过CI/CD实现自动化构建与部署，但考虑到各个微服务的特性与独立的数据，可能需要多台不同的服务器，配置过程也较为繁琐
• 分布式系统的复杂性
  由于微服务架构遵从分布式，这将带来许多挑战与困难，比如系统容错、数据同步、分布式事务、网络延迟等等的问题
• 通信接口维护成本高
  微服务之间通过内部的api交互，当其中一个api变动，其他依赖它的服务都需要做出相应的调整

设计原则

• 单一职责原则
  微服务各司其职，只关心完整系统中的一部分功能
• 服务自治原则
  微服务高度独立，与其他服务保持松耦合状态，在开发、测试、部署的过程中应当能做到独立运行而不强制依赖其他服务
• 轻量级通信机制
  微服务之间相互通信，应该通过某些比较便捷且支持跨语言跨平台的手段，比如 Rest Api，比如消息队列等
• 合理粒度原则
  合理地划分微服务的粒度，不是说代码量少就等于适合做成微服务，更要业务复杂性的体量以及与其他服务之间的关联程度

技术选型

在微服务落地中，有着一些非常不错的开源框架可供选择

• SpringCloud 一款非常优秀且成熟的微服务开源框架
• Dubbo 阿里开源的一款微服务框架
• Spring Cloud Alibaba 阿里开源的基于SpringCloud的框架
• Open Feign 出自Spring社区的Restful服务通信组件
• Nacos 阿里开源的一款强大的服务注册中心
• Seata 阿里和蚂蚁开源的分布式事务解决方案
• Nginx 高性能http和反向代理服务器
• Docker 实现微服务的容器化部署
• …

借助已有的优秀开源框架，将帮助我们更好的理解和实践微服务架构。

下一章-evp-express-cli