随便聊聊微服务

末蓝、 2022-10-30 15:25 22阅读 0赞

### 文章目录 ###

*  系统设计演进
 *  面临问题
 *  随便聊聊

# 系统设计演进 #

*  单体架构
    
    单体架构一台机器解决所有问题，最开始的系统都是部署在一台机器上的。
 *  集群架构
    
    由多个单体架构组成的一个集合，部署一样。通过负载均衡技术，分发到不同机器访问。
 *  分布式架构
    
    按照一定规则拆分到不同的服务器，通过负载均衡、分发调用技术完成完成完整业务。
 *  微服务架构
    
    按照服务化（功能区分）拆分到不同机器上，相比简单分布式架构划分更明确，粒度更小

> 从单体架构，集群架构，分布式架构，微服务架构。本质上解决的问题在于访问量的越来越大，并发的越来越高，对服务器要求越来越高。从一台到多台服务器压力的分摊来解决服务器承受压力的问题。  
> 从集群架构到分布式架构既是对服务器压力的分摊，也是资源的合理分配化，减少不必要的资源分配。

[之前写的一篇网站演变文章，更多的从技术方面去分析变化][Link 1]

[三分钟彻底弄懂什么是分布式和微服务架构][Link 2]

# 面临问题 #

1.  数据完整性
    
    微服务的拆分基本会选择独立库（也是分摊数据库压力），那么处理完整的业务、获取完整的相关数据就变得相对复杂。
    
    接口调用：目前主要解决方案是通过接口调用获取相关完整数据。此方案在代码编写上变得相对复杂。
    
    多数据源：部分业务模块可能配置多数据源，访问多数据库。此方案违背了微服务的设计，使得架构混乱，维护成本也变得高。
    
    数据冗余：部分库可以冗余相关常用数据，使得相关业务更好实现。问题是使得数据同步需要考虑相关问题，时效性、数据一致性等。
    
    使用工具：大部分情况我们会使用三方工具，如缓存（redis、mongodb）、搜索引擎（es）来进行数据整合，解决数据完整性问题。一方面减少了数据库压力，另一方面解决了数据完整性问题。同样面临的问题，数据时效性、数据一致性问题。
2.  数据一致性
    
    数据库本身支持事务，在单体架构或者集群架构中都是面对一个数据库，就不存在事务困难。但是在微服务架构中，需要在多个数据库中保证数据的一致性就变得很复杂。
    
    引入分布式锁实现分布式事务：目前一般都是通过redis或者zookeeper实现分布式锁控制分布式事务。

> 有些时候不一定非得技术层面解决问题，也可以业务层面解决问题。如：不是很重要的关联数据不一定分要展示，导致代码编写困难，从业务层面解决改变方案，从技术业务两方面折中处理。

1.  资源管理
    
    服务器资源管理：拆分的服务越来越多，服务管理就越来越困难。服务器监控、数据库监控等就变得想对困难很多。
    
    三方工具：通过三方工具进行日志采集，服务性能流量监控

[参考思维导图里面工具][Link 3]

# 随便聊聊 #

微服务盛行的年代，大部分人大部分公司为了追求新技术，新潮流。在脱离业务场景的情况下盲目追求技术。首先技术团队不一定能有驾驭各种微服务框架的能力，其二公司实际业务甚至说长期并不需要微服务的架构那种量来支撑，基本单体架构或者集群就完全能支撑。

技术为业务服务，学习归学习，真正的业务场景还是需要根据需要使用。

[Link 1]: https://blog.csdn.net/qq_28325291/article/details/82288788
[Link 2]: https://www.cnblogs.com/lfs2640666960/p/12300585.html
[Link 3]: https://gitee.com/l502387174/java-learning-mind-map/blob/master/%E4%BA%92%E8%81%94%E7%BD%91%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1/%E7%99%BE%E4%B8%87%E5%B9%B4%E8%96%AA%E6%9E%B6%E6%9E%84%E5%B8%88/%E6%9C%8D%E5%8A%A1%E6%B2%BB%E7%90%86.xmind