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

前言

从计算机诞生到如今其实也就短短几十年, 从最先的军事使用,到投入商业, 直至如今走入寻常百姓家中。用突飞猛进来形容绝不为过。 企业的服务框架, 也随着计算机的发展, 层层迭代, 由最先的单一型应用服务发展至如今知足于几亿甚至几十亿的人民的大型服务

框架的演进

1、垂直型服务

单一型应用

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

这样操做简单粗暴，运维人员只要关注这一台服务器就了事了。 可是问题来了, 若是服务器宕机了怎么办呢, 这不就意味着没法对外提供服务了吗?

主备机应用

为解决上述问题, 倒也简单, 给每台机器增长几台备机不就好了吗？ 服务器挂掉了， 快速切换服务器，依旧能及时知足对外服务。

但是问题又来了, 企业是在快速发展的啊。 企业的客户会愈来愈多, 流量愈来愈大, 单单一台服务器对外提供服务， 哪里撑得住啊， 不分分钟被搞挂掉才怪。

多机服务 + 负载均衡

因而乎， 咱们多增长几台服务器，经过负载均衡器（F5或者NGINX等）将客户请求（按负载均衡算法）合理的分配到各台机器上， 让各台机器同时提供对外服务。 这样每台服务的器压力下降了， 能快速和安全的服务于客户了。 

如今, 因为咱们提供的服务让客户很是满意, 公司赚钱了, 开始要拓展业务了, 再也不是以前的单一服务了, 咱们要作大作强。 因而咱们须要疯狂开发新模块, 对外提供更多的优质服务。 那么问题来了， 那么多模块， 咱们总不能仍是那么简单粗暴的挤在单一应用上吧。 开发人员还怎么愉快的合做了? 代码合并的时候，还不分分钟掀桌子? 并且，每台机器的算力毕竟有限， 全部模块集中在同一个应用上，不是很不合理吗?

所以，咱们须要把几个模块独立出去， 造成新的服务。当服务于服务之间存在依赖时， 再让二者进行交互， 完成数据传递。 那服务间怎么交互呢？ 这就要说说RPC了。

2、基于RPC的服务

什么是RPC

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

RPC使用

有了RPC 服务间就能愉快的进行数据传递了。 咱们的架构就能获得很好的改良了。

如今咱们的框架分红了不少独立的小模块,模块间能实时的,有效的进行消息传递。 而且业务与业务间获得很好的解耦， 机器的算力也没必要再担忧支撑不起系统了。看起来很完美。

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

所以， 咱们须要将咱们的全部服务有效的管理起来.

3、SOA

什么是SOA

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

阿里巴巴的Dubbo就是一个很是好的服务治理框架, 有兴趣的朋友能够去学习学习。

SOA的使用

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

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

咱们将每次调用状况都记录在服务监控组件上，这样服务的调用状况，健康情况就一目了然了。 更甚者，咱们能够独立一个配置中心模块，如须要修改服务的配置信息时， 经过此模块实时推送配置信息到全部或者指定的机器上，进行动态修改。 运营人员不再用一台机器一台机器的修改配置信息了。

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

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

4、微服务

什么是微服务

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

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

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

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

随着敏捷开发、虚拟化技术、DevOps 理论的实践，微服务架构愈来愈被重视与应用。 可是成熟的企业,已有成熟的架构, 彻底不必冒风险进行微服务改造。 总的来讲二者都有各自的优点, 具体如何使用, 则根据各个企业自身的考量。

总结

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

你们发现没， 每次的架构变更都是为了知足业务需求的变更和实际状况而产生的。

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

---

写得很差, 欢迎拍砖!

喜欢能够关注公众号: 终身幼稚园