Foreword
In fact, I was born and now just a few decades, from the earliest military use, to commercial, until now into the homes of ordinary people from the computer. With each passing day to describe without exaggeration. Business services framework, along with the development of computers, the layers of iterations, from the earliest single type of application development services to large service people now meet in the hundreds of millions, even billions, of
Evolution Framework
First, the vertical service
Single applications
Early on, foreign service companies to provide relatively simple, but also the relative lack of customer traffic. Thus all of the modules, the code is packaged in a project, a centralized deployment on a single machine.
Such simple rough handling, operation and maintenance personnel as long as the attention of the servers on the matter.
But the question is, if the server goes down how to do it, that does not mean that can not provide external services yet?
Application standby machine
To solve these problems, the idea is simple, to increase each machine several backup machine is not on line yet?
Server hung up, quickly switch servers, still in time to meet the foreign service.
But the problem again, business is in rapid development of ah.
Enterprise customers will be more and more traffic is growing, only a single server to provide services, where can make it ah, hang out regardless minutes was strange.
Multi-machine + service load balancing
Ever since, we have more than add a few servers through a load balancer (F5 or NGINX, etc.) to client requests (by load balancing algorithm) reasonable allocation to each machine, so that each machine while providing external services.
Such pressure is reduced for each service, fast and safe service to the customers.
Now, thanks to the services we offer so that customers are very satisfied with the company to make money, and began to expand their business, and is no longer before a single service, we become bigger and stronger.
So we need to develop new crazy module, external to provide more quality services.
So the question is, so many modules, we can not still so simple and crude squeeze it in a single application.
Developers also how happy working together? Code time of the merger, the minutes do not lift the table?
Moreover, the force count each machine is limited, all modules focused on a single application, it is not very unreasonable?
Therefore, we need to separate out several modules form a new service.
When there is a dependency between the services in the service, let the two interact to complete the data transfer.
That how the interaction between services? We will talk about the RPC.
Two, RPC service
What is 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是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。