浅谈”单体应用架构 “,”SOA”和”微服务架构”

单体应用架构

通常我们所使用的传统单体应用架构都是模块化的建设逻辑,程序在编写完成之后会被打包并部署为一个具体的应用,而应用的格式则需要依赖相关的编程语言和框架.

例如:在Molihub程序员论坛中,Java Web工程被打包成WAR包,然后部署在我的服务器上面的tomcat上.这种方式其实很常见,易于开发和调试,而且部署也很方便.

但是,在用户量不多的时候,这种方式完全可以满足需要.随着用户量的增长和请求的增加,一台服务器已经是满足不了这么大的负载,此时就需要考虑系统的水平扩展.通常情况下,我们只需要增加服务器的数量,然后将我们的应用,复制大不同服务器下的tomcat下,然后通过Nginx负载均衡就可以实现应用的水平扩展.

基本上只有我一个人在Molihub上面发帖,一个论坛成为了我的个人博客,所以现在我干脆直接另外使用Docker+WordPress搭建了一个博客

地址:CN丶Moti

有兴趣的小伙伴可以交流交流呀

下面是单体应用的架构图:

下面是单体应用的水平扩展(Nginx实现负载均衡)

单体应用的缺点如下

1. 应用复杂度增加,更新维护困难
2. 易造成系统资源浪费
3. 影响开发的效率
4. 应用可靠性低
5. 不利于技术的更新

SOA架构(Service-Oriented Architecture,面向服务的架构)

通过SOA架构可以解决单体架构应用存在的上述问题,思路就是把应用中相近的功能聚合到一起,以服务的形式提供出去,因此基于SOA架构可以理解为一批服务的组合.

SOA架构图:

由上图可以知道,SOA将原来的单体架构按照功能细分为不同的子系统,然后再由各个的子系统依赖服务中间件(这里指企业服务中线 Enterprise Service Bus,简称ESB)来调用所需的服务.

使用SOA可以将系统分为多个组件服务,这样做有很多的好处,具体如下:

• 将项目拆分为若干个子项目,由不同的团队开发
• 把模块拆分,使用接口通信,降低了模块之间的耦合度
• 更好的重用性
• 方便更新,迭代,可以只更新单个服务而不需要重写整个项目

虽然SOA解决了单体架构的问题,但多数情况下,SOA中相互独立的服务仍然会集中部署在同一个运行时环境上(类似于同一个Tomcat).和单体结构类似,随着业务功能的增加,SOA服务会变得越来越复杂.本质上看,单体架构上存在的问题并没有因为使用SOA变得更好.

随着SOA的进一步使用,微服务的思想也随之产生.

微服务架构

微服务架构是一种架构风格和架构思想,倡导我们在传统的软件应用架构的基础上,将系统业务按照功能拆分为更加细粒度的服务,所拆分的每一个服务都是一个独立的应用,这些应用对外提供公共的API,可以独立承担对外服务的职责,通过这个思想方式所开发的软件服务实体就是”微服务”,而围绕着微服务思想构建的一系列体系结构(包括开发,测试,部署等),我们可以将它称为”微服务架构”.

注意:微服务和微服务架构是两个不同的概念.微服务强调的是服务的大小,它所关注的某一个点,而微服务架构是一种架构思想,需要从整体上对软件进行全方面的考虑.

微服务架构图如下:

微服务架构的优点

1. 复杂度可控
2. 可独立部署
3. 技术选型灵活
4. 易于容错
5. 易于扩展
6. 功能特定

微服务架构的缺点

1. 开发人员必须处理创建分布式系统的复杂性
   1. 开发工具是面向单体应用的,不能为开发分布式应用提供全面的功能支持
   2. 测试更加困难
   3. 必须实现服务之间的网络通信机制
   4. 实现用例跨多个服务时,需要面向对使用分布式事务管理的困难
   5. 需要团队之间仔细协调
2. 部署的复杂性
3. 增加内存消耗

微服务架构和SOA的区别