江苏龙网

  1. 首页 > 资讯 > 科技 > >

Array|四种常见的系统架构，目前你处于哪个阶段呢？( 二 )


部署方便:可以灵活的进行分布式部署 。
提高代码的复用性：比如service层,如果不采用分布式rest服务方式架构就会在手机wap商城,微信商城,pc,android ， ios每个端都要写一个service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层 。
缺点 :系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊 。
三、微服务架构
微服务架构 ， 主要是中间层分解 ， 将系统拆分成很多小应用（微服务） ， 微服务可以部署在不同的服务器上 ， 也可以部署在相同的服务器不同的容器上 。当应用的故障不会影响到其他应用 ， 单应用的负载也不会影响到其他应用 ， 其代表框架有Spring cloud、Dubbo等 。其架构图如下所示：
微服务架构
易于开发和维护：一个微服务只会关注一个特定的业务功能 ， 所以它业务清晰、代码量较少 。开发和维护单个微服务相对简单 。而整个应用是由若干个微服务构建而成的 ， 所以整个应用也会被维持在一个可控状态 。
单个微服务启动较快：单个微服务代码量较少 ，所以启动会比较快 。
局部修改容易部署：单体应用只要有修改 ， 就得重新部署整个应用 ， 微服务解决了这样的问题 。一般来说 ， 对某个微服务进行修改 ， 只需要重新部署这个服务即可 。
技术栈不受限：在微服务架构中 ， 可以结合项目业务及团队的特点 ， 合理地选择技术栈 。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求 ， 可以使用Neo4j；甚至可根据需要 ， 部分微服务使用Java开发 ， 部分微服务使用Node.js开发 。
微服务虽然有很多吸引人的地方 ， 但它并不是免费的午餐 ， 使用它是有代价的 。使用微服务架构面临的挑战 。
运维要求较高：更多的服务意味着更多的运维投入 。在单体架构中 ， 只需要保证一个应用的正常运行 。而在微服务中 ， 需要保证几十甚至几百个服务服务的正常运行与协作 ， 这给运维带来了很大的挑战 。
分布式固有的复杂性：使用微服务构建的是分布式系统 。对于一个分布式系统 ， 系统容错、网络延迟、分布式事务等都会带来巨大的挑战 。
接口调整成本高：微服务之间通过接口进行通信 。如果修改某一个微服务的API ， 可能所有使用了该接口的微服务都需要做调整 。
重复劳动：很多服务可能都会使用到相同的功能 ， 而这个功能并没有达到分解为一个微服务的程度 ， 这个时候 ， 可能各个服务都会开发这一功能 ， 从而导致代码重复 。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件 ， 需要该功能的微服务引用该组件） ， 但共享库在多语言环境下就不一定行得通了 。
四、Serverless架构
当我们还在容器的浪潮中前行时 ， 已经有一些革命先驱悄然布局另外一个云计算战场：Serverless架构 。
Array|四种常见的系统架构，目前你处于哪个阶段呢？
文章图片

文章图片

Serverless架构
2014年11月14日 ， 亚马逊AWS发布了新产品Lambda 。当时Lambda被描述为：一种计算服务 ， 根据时间运行用户的代码 ， 无需关心底层的计算资源 。从某种意义上来说 ， Lambda姗姗来迟 ， 它像云计算的PaaS理念：客户只管业务 ， 无需担心存储和计算资源 。在此前不久 ， 2014年10月22日 ， 谷歌收购了实时后端数据库创业公司Firebase 。Firebase声称开发者只需引用一个API库文件就可以使用标准REST API的各种接口对数据进行读写操作 ， 只需编写HTML＋CSS＋JavaScrip前端代码 ， 不需要服务器端代码（如需整合 ， 也极其简单） 。
相对于上两者 ， Facebook 在2014年二月收购的 Parse ， 则侧重于提供一个通用的后台服务 。这些服务被称为Serverless或no sever 。想到PaaS（平台即服务）了是吗？很像 ， 用户不需要关心基础设施 ， 只需要关心业务 ， 这是迟到的PaaS ， 也是更实用的PaaS 。这很有可能将会变革整个开发过程和传统的应用生命周期 ， 一旦开发者们习惯了这种全自动的云上资源的创建和分配 ， 或许就再也回不到那些需要微应用配置资源的时代里去了 。


推荐阅读


上一篇：Array|微软自曝：廉价版Xbox Series S主机确认

下一篇：Array|I5+16G+512G，还带触屏——ThinkPad S2商务办公本