山东手机网站建设公司,网站建设模块下载,网站被攻击空间关了怎么办,jsp环保主题网站代做目录软件架构单体架构分布式应用微服务架构Serverless架构总结Reference软件架构
软件架构就是软件的基本结构#xff0c;合适的架构是软件成功的最重要因素之一。这里列举了目前流行的4种软件架构。
单体架构
典型的三级架构#xff1a;前端#xff08;web/手机端#…
目录软件架构单体架构分布式应用微服务架构Serverless架构总结Reference软件架构
软件架构就是软件的基本结构合适的架构是软件成功的最重要因素之一。这里列举了目前流行的4种软件架构。
单体架构
典型的三级架构前端web/手机端 中间业务逻辑层 数据库。
这是典型的Java Spring MVC 或者Python Django框架的应用。 单体架构应用容易部署测试但是随着需求不断增加会变得十分臃肿可维护性、灵活性会逐渐降低。 复杂性高一个百万行级别的单体应用整个项目包含的模块非常多模块之间的边界、依赖关系容易模糊。可能添加一个简单功能都会带来隐藏的BUG 技术债务随着时间推移、需求变更和人员更迭会逐渐形成技术债务已经使用的系统设计或代码难以被修改因为应用程序种的其他模块可能会以意料之外的方式使用它 部署频率低每次功能的变更或者缺陷的修复都会导致重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高这使得单体应用项目上线部署的频率较低。部署频率低又会导致两次发布之间会有大量的功能变更和缺陷修复出错率比较高 可靠性差某个应用BUG如死循环、内存泄露可能会导致整个应用崩溃 扩展能力受限单体应用只能作为一个整体进行扩展无法根据业务模块的需要进行伸缩。应用中有的模块是计算密集型需要强劲的CPU有的模块是IO密集型需要更多的IO资源以及内存。这些模块部署在一起的话不得不在硬件上做出妥协 阻碍技术创新单体应用往往使用统一的技术平台和方案使用相同的开发语言和框架想要引入新框架或技术平台较难
分布式应用
中级架构具有中间层分布式 数据库分布式是单体架构的并发扩展将一个大的系统划分为多个业务模块然后分别部署在不同的服务器上各个业务模块之间通过接口进行数据交互。数据库也采用分布式数据库通过Nginx代理应用将用户请求均衡地负载到不同地服务器上。 这种架构提供了负载均衡的能力大大提高了系统的负载能力解决了网站高并发的需求另外还有以下特点 解耦模块炒粉使用接口通信降低了模块之间的耦合度 责任清晰拆解为若干个子项目不同的团队负责不同的子项目 扩展方便增加功能时只需要增加一个子项目调用其他系统的接口就可以 部署方便分布式部署 提高代码复用性比如service层如果不采用分布式服务方式架构就会在pc、android、ios每个端都要写一个service层逻辑开发量大难以维护一起升级此时可以用分布式rest服务方式共用一个service层 缺点就是系统之间的交互要使用远程通信接口发开增大工作量但是利大于弊端
微服务架构
微服务架构主要是中间层分解将系统拆分成很多小应用微服务微服务可以部署在不同的服务器上也可以部署在相同的服务器的不同容器上。但应用的故障不会影响到其他应用单应用的负载也不会影响到其他应用代表框架Spring cloud、Dubbo。 微服务有以下特点
易于开发和维护一个微服务只会关注一个特定的业务功能所以业务清晰、代码量较少。开发和维护单个微服务比较简单。 单个微服务启动较快单个微服务代码量少所以启动快 局部修改容易部署单体应用只要有修改就得重新部署整个应用而某个微服务修改只需要重新部署整个服务即可 技术栈不受限制 使用微服务也是有代价的 运维要求高更多的服务意味着更多的运维投入微服务中需要保证几十个几百个服务的正常运行和协作 分布式固有的复杂性微服务构建的仍然是分布式系统系统容错、网络延迟、分布式事务也比较头疼 接口调整成本高微服务之间通过接口进行通信如果修改某一个微服务的API那么所有使用该接口的微服务都需要进行调整 重复劳动很多服务可能都会使用到相同的功能但是这个功能并没有达到分解为一个微服务的程度所以各个服务都会开发这个功能从而导致代码重复。尽管可以使用共享库但是共享库在多语言环境下不一定能用
Serverless架构
Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维由平台来按需分配计算资源并保证应用执行的SLA服务等级协议按照调用次数进行计费有效的节省应用成本。这有点像PaaS平台便是服务用户不需要关心基础设施只需要关心业务全自动云上资源创建和分配。 这种架构的优点如下 低运营成本在业务突发性极高的场景下系统为了应对业务高峰必须构建出能够应对峰值需求的系统这种系统大部分时间是空闲的这就导致了严重的资源浪费和成本上升。在微服务架构中服务需要一直运行在高负载情况下的每个服务都不止一个实例这样才能完成高可用性。Serverless架构下服务将根据用户的调用次数进行付费如果没有东西运行就不必付费。同时用户可以通过共享网络、硬盘、CPU等计算资源在业务高峰通过弹性扩容方式有效应对业务峰值在业务波谷期间将资源分享给其他用户节约成本 简化设备运维原有的IT体系中开发团队需要维护程序也需要维护硬件基础设施。在此架构中开发人员面对的是第三方的API和URL底层硬件对于开发人员透明化。 提高可维护性应用程序将调用多种第三方功能服务组成最终的应用逻辑。目前的登录鉴权服务、云数据库服务等第三方服务在安全性、可用性、性能上都进行了大量优化开发团队直接集成第三方服务能够有效的降低开发成本
总结
目前微服务架构在四种架构中处于主流地位很多应用第一、第二种架构的企业也开始慢慢转向微服务架构。第四种则是未来发展趋势
Reference
单体→分布式→微服务这些年的软件架构是怎么发育的
