分布式与微服务

 分布式：

       在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件（middleware）负责实现这个模型。一个著名的分布式系统的例子是万维网（World Wide Web），在万维网中，所有的一切看起来就好像是一个文档（Web页面）一样。（来自百科）

微服务架构：

        将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。（来自百科）

产生背景：

        在互联网还没有现在这么方便的时候，所以很多公司的业务线都是垂直架构，如LAMP。由于各个公司的业务比较简单，需要处理的用户数据也相应较少，所以简单易上手的垂直架构还能很有效地支撑各个公司的业务发展。但是随着互联网的普及移动互联网的发展，需要处理的用户数据得到了爆炸性的增长。而且为了同时服务于手机app和自助终端机等渠道的业务，各种新的需求层出不穷。在不断地迭代升级的过程中，之前提到的公司垂直应用架构慢慢就演化成了一个个的巨无霸应用。系统变得臃肿庞大，业务错综复杂。一旦有新的需求到来，牵一发而动全身。不仅系统可能有很多地方需要同时修改（比如一个访问mysql的接口，可能在代码里到处都是），而且整个系统都需要经过严格的测试才可以上线。开发效率低下，修改成本越来越高，测试周期越来越长，而bug越来越多。更让人头大的是，一旦之前维护这个项目的人员发生变动，新顶替上来的同事需要很长的时间才能把整个系统弄个半懂。所以垂直型巨无霸应用已经在大流量和高并发的冲击下，越来越力不从心。

　　这时候的解决办法便是，对复杂的巨无霸应用进行水平拆分。把公共业务包装成服务提供出来，把各个相关业务封装成子系统也提供出接口。达到降低代码耦合，公共业务复用的目的。由于子系统和子系统之间已经进行了解构，所以一些业务可以通过简单的加机器进行水平扩容来应对高并大和大流量。每个子系统的修改基本不会影响到其他子系统的稳定性，测试也不需要把整个系统拉过来全部测试一遍，提高了系统更新迭代的效率。（引用自aong5154）

CAP：

        CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

        一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

        可用性（A）：保证每个请求不管成功或者失败都有响应。

        分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。（来自百科）

BASE原理：

        BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。（来自百科）

RPC：

        RPC（Remote Procedure Call），即远程过程调用，是一种经过网络从远程计算机程序上请求服务而不须要了解底层网络技术的协议，实现调用远程主机上的方法就像调用本地方法同样。RPC协议在分布式系统中发挥重要的做用。（来自百科）