序文
実際に、私はコンピュータから普通の人々の家庭に今まで、商業用に、最古の軍事利用から、今わずか数十年に生まれました。日に日に誇張せずに記述します。ビジネスサービスフレームワークは、コンピュータの発展に伴い、アプリケーション開発サービスの最も初期のシングルタイプから大型サービスの人々への繰り返しの層は、今、何百万、数百にも、十億を満たすための
進化の枠組み
まず、垂直サービス
シングルアプリケーション
早い段階で、外資系サービス企業は、比較的単純な提供するだけでなく、顧客のトラフィックの相対的な不足します。したがって、すべてのモジュールのコードは、プロジェクト、単一のマシン上で集中配備中に包装されます。
このようなシンプルな乱暴な取り扱い、運用、保守要員限り問題に関するサーバの注意。
サーバはそれを行う方法をダウンした場合しかし、問題は、それはそれはまだ、外部のサービスを提供することができないという意味ではありませんか？
アプリケーションのスタンバイ・マシン
これらの問題を解決するために、アイデアは、各マシン複数のバックアップ・マシンがまだライン上にない増加し、簡単ですか？
サーバーはすぐに外国のサービスを満たすために、時間ではまだ、サーバを切り替え、ハングアップ。
しかし、問題は再び、ビジネスはああの急速な発展です。
企業のお客様は奇妙だった、ああ、それを作るにかかわらず分を干すことができますサービスを、提供するために、より多くのトラフィックを増加している、唯一の単一のサーバーになります。
マルチマシン+サービスのロードバランシング
各マシンが外部のサービスを提供しながら、そのよう以来、私たちは、それぞれのマシンに（ロードバランシングアルゴリズムによって）クライアントの要求にロードバランサ（F5またはnginxの、など）を介して、合理的な配分を数台のサーバを追加する以上のものを持っています。
このような圧力は、顧客への各サービス、迅速かつ安全なサービスのために減少しています。
今、私たちが提供するサービスのおかげで、顧客がお金を稼ぐために会社に非常に満足しているように、そして彼らのビジネスを拡大し始め、単一のサービスの前に、もはやあり、我々は大きく、強くなります。
だから我々は、より質の高いサービスを提供するために外部の、新しい狂気モジュールを開発する必要があります。
そこで問題は、単一のアプリケーションでは、非常に多くのモジュール、我々はできません、まだそれほど単純で、粗スクイーズそれがあります。
また、どのように幸せに一緒に取り組んで開発？合併の規範時間、分、テーブルを持ち上げないのですか？
また、各マシンを数える力は、単一のアプリケーションに焦点を当て、すべてのモジュール、それは非常に不合理ではない、制限されていますか？
したがって、我々は、新しいサービスを構成する複数のモジュールを分離する必要があります。
サービス内のサービス間の依存関係がある場合、データ転送を完了するために2つの相互作用をしましょう。
サービス間の相互作用をどのようにそれ？私たちは、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是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。