前言
从计算机诞生到现在其实也就短短几十年, 从最早的军事使用,到投入商业, 直至现在走入寻常百姓家中。用日新月异来形容毫不为过。 企业的服务框架, 也随着计算机的发展, 层层迭代, 由最早的单一型应用服务发展至现在满足于几亿甚至几十亿的人民的大型服务
框架的演进
一、垂直型服务
单一型应用
早期, 企业的对外提供的服务比较单一, 客户流量也相对不足。 因此将所有的模块，代码打包在一个项目中，集中部署一台机器上。
这样操作简单粗暴，运维人员只要关注这一台服务器就了事了。
但是问题来了, 如果服务器宕机了怎么办呢, 这不就意味着无法对外提供服务了吗?
主备机应用
为解决上述问题, 倒也简单, 给每台机器增加几台备机不就行了吗？
服务器挂掉了， 快速切换服务器，依旧能及时满足对外服务。
可是问题又来了, 企业是在快速发展的啊。
企业的客户会越来越多, 流量越来越大, 单单一台服务器对外提供服务， 哪里撑得住啊， 不分分钟被搞挂掉才怪。
多机服务 + 负载均衡
于是乎， 我们多增加几台服务器，通过负载均衡器（F5或者NGINX等）将客户请求（按负载均衡算法）合理的分配到各台机器上， 让各台机器同时提供对外服务。
这样每台服务的器压力降低了， 能快速和安全的服务于客户了。
现在, 由于我们提供的服务让客户非常满意, 公司赚钱了, 开始要拓展业务了, 不再是之前的单一服务了, 我们要做大做强。
于是我们需要疯狂开发新模块, 对外提供更多的优质服务。
那么问题来了， 那么多模块， 我们总不能还是那么简单粗暴的挤在单一应用上吧。
开发人员还怎么愉快的合作了? 代码合并的时候，还不分分钟掀桌子?
而且，每台机器的算力毕竟有限， 所有模块集中在同一个应用上，不是很不合理吗?
因此，我们需要把几个模块独立出去， 形成新的服务。
当服务于服务之间存在依赖时， 再让两者进行交互， 完成数据传递。
那服务间怎么交互呢？ 这就要说说RPC了。
二、RPC服务
什么是RPC
RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
RPC使用
有了RPC 服务间就能愉快的进行数据传递了。
我们的架构就能得到很好的改良了。
现在我们的框架分成了很多独立的小模块,模块间能实时的,有效的进行消息传递。
并且业务与业务间得到很好的解耦， 机器的算力也不必再担心支撑不起系统了。看起来很完美。
可是，运营人员不干了: 现在服务那么分散， 机器那么多，让我怎么管理？ 哪天哪台服务挂掉了， 让我上哪找去？
因此， 我们需要将我们的所有服务有效的管理起来。
三、SOA
什么是SOA
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
阿里巴巴的Dubbo就是一个非常好的服务治理框架, 有兴趣的朋友可以去学习学习。
SOA的使用
通过SAO的服务治理方案, 我们将我们的框架进行终极改良。
- 将所有的服务提供者注册到注册中心。
- 客户端向注册中心订阅服务
- 注册中心向客户端推送有效的服务信息
- 客户端得到所有可调用服务的信息后， 根据需求，按负载均衡算法， 进行调用， 获取数据。
我们将每次调用情况都记录在服务监控组件上，这样服务的调用情况，健康状况就一目了然了。
更甚者，我们可以独立一个配置中心模块，如需要修改服务的配置信息时， 通过此模块实时推送配置信息到所有或者指定的机器上，进行动态修改。 运营人员再也不用一台机器一台机器的修改配置信息了。
至此， 我们的框架可以有效的满足不断扩张的业务需求以及保证机器的平稳运行了。 到这里, 框架可以算是暂时定型了, 短期内, 不会再做什么大规模的改造了。
到这里就结束了吗?那接下来的微服务又是什么呢, 还有必要升级吗?
四、微服务
什么是微服务
微服务架构的系统是一个分布式的系统,每个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发，甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。
说的微服务, SpringCloud是绕不开的话题, 有兴趣的朋友可以去学习学习。
微服务和SOA的差异
SOA和微服务一脉相承, 都是面向服务的治理方案
- 微服务颗粒度更细, 一个系统拆成多个服务, SOA颗粒度更大
- 微服务功能独立, 独立部署; SOA单体架构,业务耦合
- 微服务服务自治, 松散管理; SOA集中式管理
随着敏捷开发、虚拟化技术、DevOps 理论的实践，微服务架构越来越被重视与应用。
但是成熟的企业,已有成熟的架构, 完全没必要冒风险进行微服务改造。
总的来说两者都有各自的优势, 具体如何使用, 则根据各个企业自身的考量。
总结：
简单来说企业应用架构演变(不严谨的说)：从垂直架构模式(MVC)----->PRC架构模式------->到SOA模式-------->微服务。
垂直架构：早期客户流量较少，所有的业务模块都是存放在一个项目里，部署配一台服务器就能解决我们的需求。
但是如果就这一台服务器挂了，就不能再为用户提供服务，所以有了多台服务器，以备不时之需。
但是虽然有备用的服务器，可归根到底应用资源还是都跑在一台服务器中，这就造成了资源浪费，所以就加入了负载均衡，就是说不能就人一台服务器干活！！！你们剩下的服务器也要分单压力，于是这样既能不浪费资源，还安全有效的服务了客户。
RPC架构：RPC（Remote Procedure Call）远程过程调用。而PRC架构的引入，是为了解决应用与应用之间的交互问题。当垂直应用越来越多，应用之间交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。此时，用于提高业务复用及拆分的RPC框架是关键。他的底层是通过socket通信和序列化反序列化实现的。
底层原理：https://www.cnblogs.com/huangqingshi/p/7803642.html66
SOA架构：SOA架构的特点就是服务中心 随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的SOA服务治理是关键。
特点:
- 将所有的服务提供者注册到注册中心。
- 客户端向注册中心订阅服务
- 注册中心向客户端推送有效的服务信息
- 客户端得到所有可调用服务的信息后， 根据需求，按负载均衡算法， 进行调用， 获取数据。
例子：阿里巴巴的Dubbo框架
微服务：可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
微服务的目的：是有效的拆分应用，实现敏捷开发和部署 。
微服务提倡的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。