企业应用架构的发展演进

时间 2019-11-12

原文原文链接

前言

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

框架的演进

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 理论的实践，微服务架构愈来愈被重视与应用。

可是成熟的企业,已有成熟的架构, 彻底不必冒风险进行微服务改造。

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

总结：

　　简单来讲企业应用架构演变(不严谨的说)：从垂直架构模式(MVC)----->PRC架构模式------->到SOA模式-------->微服务。

　　垂直架构：早期客户流量较少，全部的业务模块都是存放在一个项目里，部署配一台服务器就能解决咱们的需求。

　　　　　　　　可是若是就这一台服务器挂了，就不能再为用户提供服务，因此有了多台服务器，以备不时之需。

　　　　　　　　可是虽然有备用的服务器，可归根到底应用资源仍是都跑在一台服务器中，这就形成了资源浪费，因此就加入了负载均衡，就是说不能就人一台服务器干活！！！大家剩下的服务器也要分单压力，因而这样既能不浪费资源，还安全有效的服务了客户。

　 RPC架构：RPC（Remote Procedure Call）远程过程调用。而PRC架构的引入，是为了解决应用与应用之间的交互问题。当垂直应用愈来愈多，应用之间交互不可避免，将核心和公共业务抽取出来，做为独立的服务，实现先后台逻辑分离。此时，用于提升业务复用及拆分的RPC框架是关键。他的底层是经过socket通讯和序列化反序列化实现的。

　　底层原理：http://www.javashuo.com/article/p-ygkjnhba-gr.html66

SOA架构：SOA架构的特色就是服务中心随着业务发展，服务数量愈来愈多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提高服务质量的SOA服务治理是关键。

　特色:

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

　　例子：阿里巴巴的Dubbo框架

微服务：能够独立的部署、运行、升级，不只如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的总体。这种所谓的“统一的总体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
　　 微服务的目的：是有效的拆分应用，实现敏捷开发和部署。
　　　　微服务提倡的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，缘由就是由于若是团队按照这样的方式组建，将沟通的成本维持在系统内部，每一个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能下降。