随着服务的壮大,使用人数的增多,业务的递增,服务的扩展性尤为关键,在不影响现有架构的情况下如何增加机器、扩展功能?
一个字: 拆 。把大的系统拆为小的系统,下面是拆分的几个不同方法,也是拆分依赖的不同维度,以学生信息管理系统为例:
那么我们作为架构师,应该如何选择呢?就是需要明白不同拆分方式的优缺点,适用的场景:
很常见的架构模式,也叫N层架构,N至少是2,比如:
1)C/S、B/S架构
划分的对象时整个业务系统,将和用户交互的部分独立为一层,后台作为另外一层,如图:
2)MVC架构
划分的对象是单个业务系统,将不同的职责划分开
3)逻辑分层架构
划分的对象可以是单个业务子系统,也可以是整个业务系统,将不同的职责划分开,与MVC架构不同在于逻辑分层架构中的层是自顶向下依赖的。比如操作系统内核架构、TCP/IP架构,比如安卓操作系统:
分层架构的核心在于: 保证各层之间的职责差异足够清晰 。之所以能够支撑系统扩展,本质在于隔离关注点,就是每层中的组件只处理本层的逻辑。这样就可以支持系统在某层上的快速扩展
但是除开分层,还需要保证层与层之间的依赖是稳定的,才能真正支撑快速扩展,这个依赖就是接口
Linux内核为支撑不同的文件系统格式,抽象出来VFS文件系统接口,如上。如果没有VFS,那么即使增加一个文件系统,也无法将依赖文件系统的系统应用上新的文件系统,因为并不知道接口是什么,而VFS统一了
优势:各层之间自顶而下结构清晰、强制约束层之间的关系是两两依赖,依赖的数量固定
缺点:如果层级多,强制两两依赖将导致性能、实现上的浪费,架构也会混乱
场景:适用互联网架构整体分层、操作系统分层,不适合互联网架构后台服务
Service Oriented Architecture,面向服务的架构,是上世纪90年代就已经出现的架构模式:
微服务这几年很火,但也在早就出来了,只不过Martin Fowler将它发扬光大
与SOA的区别:
但微服务的坑是相当的多,稍有不慎就会陷入焦油坑,最后发现某些情况下几个单体应用的架构甚至甩了微服务好几条街
比如:服务划分过细导致服务关系复杂、团队开发效率下降、调用链太长性能下降、定位问题困难、对运维自动化要求极高、微服务数量递增管理难度极大…从而步了SOA的后尘
更多微服务资料可参看: https://www.wangtianyi.top/blog/2017/04/16/microservies-1-introduction-to-microservies/
包含两类组件:
比如在规则引擎架构上有以下体现,比如电商促销中会有很多规则,不可能把规则都写到代码里,那样完全无法有效扩展,架构如下:
设计关键点在于:
https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/
最近在总结一些针对 Java 面试相关的知识点,感兴趣的朋友可以一起维护~
地址: https://github.com/xbox1994/2018-Java-Interview