认识达内从这里开始

软件架构技术随着互联网的不断发展而越来越多样化，今天我们就通过案例分析来了解一下，常见的软件架构类型都有哪些。

分布式架构

分布式应用架构中，相互独立，代码独立开发，独立部署，通过API接口互相通信。通讯协议一般使用HTTP/RPC，数据格式是JSON(是一种轻量级的数据交换格式)，应用集成方式比较简化。

优点:应用内部高内聚，独立开发、测试和部署，应用之间松耦合，业务边界清晰，业务依赖明确，支持大项目并行开发。

缺点:API接口需求变化，应用就需要重新部署，通信可靠性和数据的封装性相对于进程内调用比较差。

SOA架构

SOA也是分布式应用架构一种。

SOA架构提供配套的服务治理，包括服务注册、服务路由、服务授权、服务降级、服务监控等等。

SOA架构既体现业务的拆分，又体现业务的整合，更多地从业务整体上考虑系统拆分。

优点：以服务层为主，聚焦核心业务，同时以提供整个系统共享，服务作为独立的应用，独立部署，接口清晰，很容易做自动化测试和部署，服务是无状态的，很容易做水平扩展;通过容器虚拟化技术，实现故障隔离和资源高效利用。

缺点：系统依赖复杂，给开发/测试/部署带来不便，分布式数据一致性和分布式事务支持困难，一般通过终一致性简化解决。

单体式应用

系统只有一个应用、打包成一个应用;部署在一台机器;在一个DB里存储数据，单体式应用采用分层架构，一般为表示层、业务层、数据访问层、DB层，表示层负责用户体验，业务层负责业务逻辑，数据访问层负责DB层的数据存取

优点：开发、编译、调试一站式、一个应用程序包含所有功能点，容易测试和部署

缺点：系统逐渐庞大时，代码复杂度高，难以维护，应用扩展水平低，业务和模块职责区分不清晰。

微服务架构

微服务架构(microservicesarchitecture)是服务导向架构(service-orientedarchitecture，缩写SOA)的升级。

每一个服务就是一个独立的部署单元(separatelydeployedunit)。这些单元都是分布式的，互相解耦，通过远程通信协议(比如REST、SOAP)联系。

微服务架构分成三种实现模式。

RESTfulAPI模式：服务通过API提供，云服务就属于这一类

RESTful应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部

集中消息模式：采用消息代理(messagebroker)，可以实现消息队列、负载均衡、统一日志和异常处理。缺点：是会出现单点失败，消息代理可能要做成集群。

优点：扩展性好，各个服务之间低耦合

容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元

容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级

易于测试，可以单独测试每一个服务

缺点

由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳。

一旦服务之间需要通信(即一个服务要用到另一个服务)，整个架构就会变得复杂。例子就是一些通用的Utility类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性。

分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。