目录
1、高并发架构
2、异地多活架构
3、容器化架构
4、微服务架构
5、高可用架构
6、弹性化架构
1、DevOps
2、应用监控
3、自动化运维
4、SOA 服务治理
5、去 IOE
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
通俗理解：由于业务间的逻辑越来越复杂，我们就不把这些业务全部杂糅在一起，每个业务都分开来做，这就是微服务，而微服务就是一种特殊的分布式。
优缺点
优点：上面的单体系统全部运行于一个进程之内，资源相互影响，添加功能可能会影响其它功能，导致维护麻烦。 而微服务一切分为不同的模块，运行于自身进程内，而且不同的服务可以使用不同的语言充分发挥优势。
缺点：引入了分布式的复杂性，如接口一致性。 不过很多问题强大的Spring Cloud都已经提供了解决方案！
1、通过服务实现组件化。开发者不再需要协调其它服务部署对本服务的影响。
2、按业务能力来划分服务和开发团队。开发者可以自由选择开发技术，提供 API 服务
3、去中心化。每个微服务有自己私有的数据库持久化业务数据
每个微服务只能访问自己的数据库，而不能访问其它服务的数据库，某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
4、基础设施自动化（devops、自动化部署）的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。
5、主要区别：
| 功能 |
SOA |
微服务 |
| 组件大小 |
大块业务逻辑 |
单独任务或小块业务逻辑 |
| 耦合 |
通常松耦合 |
总是松耦合 |
| 公司架构 |
任何类型 |
小型、专注于功能交叉团队 |
| 管理 |
着重中央管理 |
着重分散管理 |
| 目标 |
确保应用能够交互操作 |
执行新功能、快速拓展开发团队 |
SOA:（Service Oriented Architecture） 面向服务的架构。把工程拆分成服务层、表现层两个工程，服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
SOA是一个组件模型，它将应用程序的不同功能单元（成为服务），通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，他应该独立于实现服务的硬件平台、操作系统、和变成语言。这是的构建在各种各样的系统中的服务可以从一种统一和通用的方式进行交互。
SOA是把服务分成了若干，表现层分成了若干。表现层和服务层没有耦合关系，表现层可以用任意一个服务层，开发的时候，仅仅是增加服务层和Web层2个工程，并不会把服务层和Web层当成一个整个工程。他们是独立的。而分布式架构是Web和服务层紧紧联系到了一起，一个web层对应一个服务层。所以SOA比分布式架构更加解耦合。扩展也更容易。
SOA优缺点
优点：敏捷性、一致性、业务流程的改进、灵活性、数据统一、运行监控、利用操作平台。
缺点：组织结构的改变、组织权力结构的改变、业务面临的新挑战、IT变得简单之前会越来越复杂、没有数据视图、监控复杂性、技术不匹配。
SOA特征：
1、可重用。解决了分布式的缺点。不同的web层可以共用一个服务层。
2、松耦合。服务请求者到服务提供者的绑定与服务之间是松耦合的，服务请求者不需要知道服务提供者实现的技术细节。
3、明确定义的接口。
4、无状态的服务设计。服务不应该依赖其他服务的上下文和状态。当产生依赖时，他们可以定义成通用的业务流程，函数和数据模型。
5、基于开放标准。
SOA体系结构中的角色包括：
1、服务请求者
是一个应用程序、一个软件模块、另一个服务。他发起对注册中心的服务的查询，通过传输绑定服务、并且执行服务功能，服务请求者根据接口契约来执行服务。
2、服务提供者
是一个可通过网络寻址的实体，他接受和执行来自请求者的请求，他将自己的服务和接口契约发布到服务注册中心。
3、服务注册中心
是服务发现的支持者，他包含一个可用服务的存储库，并运行感兴趣的服务请求者查询服务提供者接口。
系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】
系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】
业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】。
首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。
1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
2.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
1.ESB（企业服务总线），简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通；
2.API网关:API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
微服务网关 = 传统ESB + 去掉了复杂服务适配和协议转换 +去掉了服务编排 + 提升了限流容错能力
一个业务分拆成多个子业务，或者本身就是不同的业务，部署在不同的服务器上。
简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个均衡服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成，并且一台服务器垮了，其它的服务器可以顶上来。分布式的每一个节点，都完成不同的业务，一个节点垮了，那这个业务可能就失败了。
计算机集群通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机，比如工作站或超级计算机性能价格比要高得多。
比如单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。一般分为几种：
高可用性集群：一般是指当集群中有某个节点失效的情况下，其上的任务会自动转移到其他正常的节点上。还指可以将集群中的某节点进行离线维护再上线，该过程并不影响整个集群的运行。
负载均衡集群：负载均衡集群运行时，一般通过一个或者多个前端负载均衡器，将工作负载分发到后端的一组服务器上，从而达到整个系统的高性能和高可用性。
高性能计算集群：高性能计算集群采用将计算任务分配到集群的不同计算节点而提高计算能力，因而主要应用在科学计算领域。
随着业务量的提高，现有网络的各个核心部分访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。
负载均衡技术通过设置虚拟服务器IP（VIP），将后端多台真实服务器的应用资源虚拟成一台高性能的应用服务器，通过负载均衡算法，将用户的请求转发给后台内网服务器，内网服务器将请求的响应返回给负载平衡器，负载平衡器再将响应发送到用户，这样就向互联网用户隐藏了内网结构，阻止了用户直接访问后台（内网）服务器，使得服务器更加安全，可以阻止对核心网络栈和运行在其它端口服务的攻击。并且负载均衡设备（软件或硬件）会持续的对服务器上的应用状态进行检查，并自动对无效的应用服务器进行隔离，实现了一个简单、扩展性强、可靠性高的应用解决方案，解决了单台服务器处理性能不足，扩展性不够，可靠性较低的问题。
系统的扩展可分为纵向（垂直）扩展和横向（水平）扩展。纵向扩展，是从单机的角度通过增加硬件处理能力，比如CPU处理能力，内存容量，磁盘等方面，实现服务器处理能力的提升，不能满足大型分布式系统（网站），大流量，高并发，海量数据的问题。因此需要采用横向扩展的方式，通过添加机器来满足大型网站服务的处理能力。比如：一台机器不能满足，则增加两台或者多台机器，共同承担访问压力。
负载平衡最重要的一个应用是利用多台服务器提供单一服务，这种方案有时也称之为服务器农场。通常，负载平衡主要应用于Web网站，大型的Internet Relay Chat网络，高流量的文件下载网站，NNTP（Network News Transfer Protocol）服务和DNS服务。现在负载平衡器也开始支持数据库服务，称之为数据库负载平衡器。
服务器负载均衡有三大基本Feature：负载均衡算法，健康检查和会话保持，这三个Feature是保证负载均衡正常工作的基本要素。其他一些功能都是在这三个功能之上的一些深化。下面我们具体介绍一下各个功能的作用和原理。
在没有部署负载均衡设备之前，用户直接访问服务器地址（中间或许有在防火墙上将服务器地址映射成别的地址，但本质上还是一对一的访问）。当单台服务器由于性能不足无法处理众多用户的访问时，就要考虑用多台服务器来提供服务，实现的方式就是负载均衡。负载均衡设备的实现原理是把多台服务器的地址映射成一个对外的服务IP（我们通常称之为VIP，关于服务器的映射可以直接将服务器IP映射成VIP地址，也可以将服务器IP:Port映射成VIP:Port，不同的映射方式会采取相应的健康检查，在端口映射时，服务器端口与VIP端口可以不相同）,这个过程对用户端是不可见的，用户实际上不知道服务器是做了负载均衡的，因为他们访问的还是一个目的IP，那么用户的访问到达负载均衡设备后，如何把用户的访问分发到合适的服务器就是负载均衡设备要做的工作了，具体来说用到的就是上述的三大Feature。
1、分布式处理，但只有一个总数据库，没有局部数据库
2、分层式处理，每一层都有自己的数据库
3、充分分散的分布式网络，没有中央控制部分，各节点之间的联系方式又可以有多种，如松散的联接，紧密的联接，动态的联接，广播通知式的联接等
简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同
微服务是啥？这里不引用书本上的复杂概论了，简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。
微服务架构又是啥？在做架构设计的时候，先做逻辑架构，再做物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器能否满足需求，如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里，如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。
那么分布式又是啥？分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。
微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。
有 分布式文件系统，分布式缓存系统，分布式数据库，分布式WebService，分布式计算
我们来举例说明：
分布式文件系统： 出名的有 Hadoop 的HDFS ,还有 google的 GFS , 淘宝的 TFS 等
分布式缓存系统：memcache , hbase , mongdb 等
分布式数据库 ： MySQL , Mariadb, PostgreSQL 等
以分布式MySQL数据库中间件MyCat 为例子，
MySQL 在现在电商以及互联网公司的应用非常多，一个是因为他的免费开源，另外一个原因是因为分布式系统
的水平可扩展性，随着移动互联网用户的暴增，互联网公司，像淘宝，天猫，唯品会等电商都采用分布式系统应对
用户的高并发量以及大数据量的存储。
而在Mycat的商业案例中，有对中国移动的账单结算项目中，应用实时处理高峰期每天2亿的数据量，
在对物联网的项目中，实现处理高达26亿的数据量，并提供实时查询的接口。
通过对MyCat的学习，加深分布式系统架构的理解，
以及分布式相关的技术，分布式一致性ZooKeeper服务, 高可用HAProxy/keepalived等相关应用。
1> 集群 与 分布式
2> 负载均衡
3> 分布式相关的高可用、容灾等名词解释
4> Mycat 中间件学习
