简单聊聊企业应用架构的演变

前言

从计算机诞生到现在其实也就短短几十年, 从最早的军事使用,到投入商业, 直至现在走入寻常百姓家中。用日新月异来形容毫不为过。 企业的服务框架, 也随着计算机的发展, 层层迭代, 由最早的单一型应用服务发展至现在满足于几亿甚至几十亿的人民的大型服务

框架的演进

一、垂直型服务

单一型应用

早期, 企业的对外提供的服务比较单一, 客户流量也相对不足。 因此将所有的模块，代码打包在一个项目中，集中部署一台机器上。

这样操作简单粗暴，运维人员只要关注这一台服务器就了事了。

但是问题来了, 如果服务器宕机了怎么办呢, 这不就意味着无法对外提供服务了吗?

主备机应用

为解决上述问题, 倒也简单, 给每台机器增加几台备机不就行了吗？

服务器挂掉了， 快速切换服务器，依旧能及时满足对外服务。

可是问题又来了, 企业是在快速发展的啊。

企业的客户会越来越多, 流量越来越大, 单单一台服务器对外提供服务， 哪里撑得住啊， 不分分钟被搞挂掉才怪。

多机服务 + 负载均衡

于是乎， 我们多增加几台服务器，通过负载均衡器（F5或者NGINX等）将客户请求（按负载均衡算法）合理的分配到各台机器上， 让各台机器同时提供对外服务。

这样每台服务的器压力降低了， 能快速和安全的服务于客户了。

现在, 由于我们提供的服务让客户非常满意, 公司赚钱了, 开始要拓展业务了, 不再是之前的单一服务了, 我们要做大做强。

于是我们需要疯狂开发新模块, 对外提供更多的优质服务。

那么问题来了， 那么多模块， 我们总不能还是那么简单粗暴的挤在单一应用上吧。

开发人员还怎么愉快的合作了? 代码合并的时候，还不分分钟掀桌子?

而且，每台机器的算力毕竟有限， 所有模块集中在同一个应用上，不是很不合理吗?

因此，我们需要把几个模块独立出去， 形成新的服务。

当服务于服务之间存在依赖时， 再让两者进行交互， 完成数据传递。

那服务间怎么交互呢？ 这就要说说RPC了。

二、RPC服务

什么是RPC

RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

RPC使用

有了RPC 服务间就能愉快的进行数据传递了。

我们的架构就能得到很好的改良了。

现在我们的框架分成了很多独立的小模块,模块间能实时的,有效的进行消息传递。

并且业务与业务间得到很好的解耦， 机器的算力也不必再担心支撑不起系统了。看起来很完美。

可是，运营人员不干了: 现在服务那么分散， 机器那么多，让我怎么管理？ 哪天哪台服务挂掉了， 让我上哪找去？

因此， 我们需要将我们的所有服务有效的管理起来。

三、SOA

什么是SOA

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

阿里巴巴的Dubbo就是一个非常好的服务治理框架, 有兴趣的朋友可以去学习学习。

SOA的使用

通过SAO的服务治理方案, 我们将我们的框架进行终极改良。

• 将所有的服务提供者注册到注册中心。
• 客户端向注册中心订阅服务
• 注册中心向客户端推送有效的服务信息
• 客户端得到所有可调用服务的信息后， 根据需求，按负载均衡算法， 进行调用， 获取数据。

我们将每次调用情况都记录在服务监控组件上，这样服务的调用情况，健康状况就一目了然了。

更甚者，我们可以独立一个配置中心模块，如需要修改服务的配置信息时， 通过此模块实时推送配置信息到所有或者指定的机器上，进行动态修改。 运营人员再也不用一台机器一台机器的修改配置信息了。

至此， 我们的框架可以有效的满足不断扩张的业务需求以及保证机器的平稳运行了。 到这里, 框架可以算是暂时定型了, 短期内, 不会再做什么大规模的改造了。

到这里就结束了吗?那接下来的微服务又是什么呢, 还有必要升级吗?

四、微服务

什么是微服务

微服务架构的系统是一个分布式的系统,每个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发，甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。

说的微服务, SpringCloud是绕不开的话题, 有兴趣的朋友可以去学习学习。

微服务和SOA的差异

SOA和微服务一脉相承, 都是面向服务的治理方案

• 微服务颗粒度更细, 一个系统拆成多个服务, SOA颗粒度更大
• 微服务功能独立, 独立部署; SOA单体架构,业务耦合
• 微服务服务自治, 松散管理; SOA集中式管理

随着敏捷开发、虚拟化技术、DevOps 理论的实践，微服务架构越来越被重视与应用。

但是成熟的企业,已有成熟的架构, 完全没必要冒风险进行微服务改造。

总的来说两者都有各自的优势, 具体如何使用, 则根据各个企业自身的考量。

总结

本文不严谨地介绍了企业框架演变的过程。

大家发现没， 每次的架构变动都是为了满足业务需求的变动和实际情况而产生的。

没错，任何不以业务为基础的框架, 都是耍流氓…