架构演进之路
随着业务的不断发展，数据量越来越多，用户量越来越大，系统架构也在不断的发展。架构思路，就是拆分，拆分分为垂直拆分和水平拆分，对于数据库来说，垂直拆分相当于分库，水平拆分相当于分表，对于应用来说，垂直拆分是从业务维度来的，水平拆分是从功能维度来的。
单体架构
单业务量不大的时候，架构可能是这样的，应用和数据库一个服务器。
也可能是这样的，应用和数据库分库，各自拥有服务器的CPU、内存、IO、网络等资源。
还有有可能是这样的，应用部署多份于多个服务器，通过负载均衡（比如nginx）对请求进行转发。
负载均衡是集群的一种应用，把请求分摊到各个应用，提高并发处理能力。当然，这个时候，有个问题需要解决，就是session共享的问题。比如Session Sticky、session Replication、session集中存储、cookie（jwt）等方式可以解决session共享的问题。
垂直架构/水平架构
单体架构，在业务量不大、研发人员较少的时候，是比较常用的。这是因为开发、测试、部署甚至扩展（直接复制多份接入负载均衡）都是非常简单的。但是在业务系统不断壮大的时候，就开始显示出弊端来，比如系统耦合性太高，修改部分功能都要全部部署，A功能和B功能访问量可能差好几个等级，部署的时候却要捆绑部署，浪费资源；开发效率低下，系统太庞大，维护、开发新功能互相冲突等；稳定性差，可能一个功能导致整个应用不可用等，这个时候，就要对应用进行拆分了，拆分后，每个服务都可以独立部署、开发。
垂直拆分
把应用根据业务拆分成商品、用户、订单三个应用，每个应用里面继续集群。每个应用服务，还是一个单体架构。
水平拆分
根据功能维度，把应用拆分成网关层、业务逻辑层、数据访问层。
如果各个应用有共用的地方，就把他抽取出来下沉，比如商品业务逻辑和用户业务逻辑都可以访问商品业务逻辑的下沉部分。这边只能从上到下访问，不能从左到右，防止互相访问。
网关层：日志、限流降级熔断、认证等，常用网关有zuul、Spring Cloud Gateway、Nginx、Kong等
业务逻辑层：对业务逻辑的操作
数据访问层：对数据库的操作，屏蔽了底层存储的差异性。
可以看到，架构越来越复杂，后续追踪问题的难度也逐步提高，而且链路越来越长，延时也会相应变高。
微服务架构
微服务就是垂直拆分+水平拆分。
使用场景，从下面三个来考虑：
- 需求层面：需求变化比较频繁。
- 性能层面：吞吐量要求比较高。
- 数据一致性层面：最终一致性（强一致性导致吞吐量不高）。
微服务优点：
- 项目快速迭代
- 项目持续交付
微服务缺点：
- 微服务架构中，应用集成了服务注册发现、服务负载均衡、服务降级、服务熔断、服务链路跟踪等，使得我们实际开发过程中，还是要关注这些组件，导致我们的业务迭代速度降低。
- 这些组件，在升级的过程中，由于是团队间合作，导致整体的交付能力和交付速度有了一定的影响。
- 每个业务，可能用的语言不一致，每次组件的升级，由于是多种语言写的，并不能共用，导致重复量开发。
那我们要如何解决这些缺点呢？
服务网格架构
服务网格，作为服务间通信的基础设施层，负责服务之间的网络调用、限流、熔断和监控。在运行的过程中，由于对应用程序来说是透明的，所以业务团队只关注业务逻辑，与基础设施团队物理解耦。
目前流行的Service Mesh开源软件有 Linkerd 、 Envoy 和 Istio 等。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
