通过这篇文章我们来学习我们项目系统架构的演变过程。没部署过项目的或者没做过项目的小伙伴也可以康康,hhhh..
当我们系统的用户逐渐增多,我们系统就必须具备了高可用、高并发这样的特性。如何解决?
1、单体应用架构
这种应用架构就是我们在校园中做项目(例如一个网站、一个小程序等)经常用的架构,说白了,学校也不可能给你几台服务器让你玩分布式,第一是有这种需求也不会交给学生做,第二是学校的系统一般的并发量还没达到这个级别。我个人现在大三,在学校做过大大小小很多系统,到最后说白了就是反复做同一个事,也没啥难的(吹个牛B)。
优点:(1)所有的功能集成在一个项目工程中(2)项目架构简单,前期开发成本低,周期短,小型项目的首选。
缺点:(1)全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护(2)系统性能扩展只能通过扩展集群结点,成本高、有瓶颈。 (3)技术栈受限(4)容错不好,如果其中一个模块出现问题,可能导致整个项目崩掉。
单体应用架构
2、垂直应用架构
当访问量增加,我们就得想一下如何解决问题。将应用拆成互不相干的几个应用,以提升效率
这里将三个模块系统,部署到三台服务器上,这样各自应用不会互相干扰,形成分流。三个系统是毫无关系的,但是这样我们就需要写一些重复的开发代码了,比如后台管理系统要看到电商系统的数据,那么必然调用电商系统的数据内容。这个架构并没有根本上解决高并发的问题。只是将原来的项目,一刀切为3份而已。
优点:(1)项目架构简单,前期开发成本低,周期短,小型项目的首选。(2)通过垂直拆分,原来的单体项目不至于无限扩大(3)不同的项目可采用不同的技术。
缺点:(1)全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护。(2)系统性能扩展只能通过扩展集群结点,成本高、有瓶颈。
3、分布式SOA架构
4、微服务架构
5、soa和微服务的关系
SOA( Service Oriented Architecture )“面向服务的架构”:他是一种设计方法,其中包含多个服 务, 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程 中。各个服务之间 通过网络调用。
功能
|
SOA
|
微服务
|
组件大小
|
大块业务逻辑
|
单独任务或小块业务逻辑
|
耦合
|
通常松耦合
|
总是松耦合
|
公司架构
|
任何类型
|
小型、专注于功能交叉团队
|
管理
|
着重中央管理
|
着重分散管理
|
目标
|
确保应用能够交互操作
|
执行新功能、快速拓展开发团队
|