微服务架构
资料来源：有架构给个人一些资料，以及本身百度和论坛、社区找来的一些资料，权当作一个总结式的简介。。。git
目录以下：github
1、微服务架构介绍web
2、出现和发展算法
3、传统开发模式和微服务的区别docker
4、微服务的具体特征数据库
5、SOA和微服务的区别设计模式
6、如何具体实践微服务数组
7、常见的微服务设计模式和应用缓存
8、微服务的优势和缺点安全
9、思考：意识的转变
10、参考资料和推荐阅读
1、微服务架构介绍
微服务架构（Microservice Architecture）是一种架构概念，旨在经过将功能分解到各个离散的服务中以实现对解决方案的解耦。你能够将其看做是在架构层次而非获取服务的
类上应用不少SOLID原则。微服务架构是个颇有趣的概念，它的主要做用是将功能分解到离散的各个服务当中，从而下降系统的耦合性，并提供更加灵活的服务支持。
概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而知足服务等级协议。
定义：围绕业务领域组件来建立应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
2、出现和发展
微服务（Microservice）这个概念是2012年出现的，做为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，能够说是微服务的元年；
愈来愈多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，能够说这样更近一步推进了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。
这老头是个奇人，特别擅长抽象概括和制造概念。特别是微服务这种新生的名词，都有一个特色：一解释就懂，一问就不知，一讨论就打架。
Martin Fowler是国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首
席科学家。在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界顶级的
专家，现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和——集
成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几
本经典书籍： 《企业应用架构模式》、《UML精粹》和《重构》等。
———— 百度百科
3、传统开发模式和微服务的区别
先来看看传统的web开发方式，经过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式通常被称为Monolithic（单体式开发）。
全部的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等全部逻辑。
优势：
①开发简单，集中式管理
②基本不会重复开发
③功能都在本地，没有分布式的管理和调用消耗
缺点：
一、效率低：开发都在同一个项目改代码，相互等待，冲突不断
二、维护难：代码功功能耦合在一块儿，新人不知道何从下手
三、不灵活：构建时间长，任何小修改都要重构整个项目，耗时
四、稳定性差：一个微小的问题，均可能致使整个应用挂掉
五、扩展性不够：没法知足高并发下的业务需求
常见的系统架构遵循的三个标准和业务驱动力：
一、提升敏捷性：及时响应业务需求，促进企业发展
二、提高用户体验：提高用户体验，减小用户流失
三、下降成本：下降增长产品、客户或业务方案的成本
基于微服务架构的设计：
目的：有效的拆分应用，实现敏捷开发和部署
关于微服务的一个形象表达：
X轴：运行多个负载均衡器以后的运行实例
Y轴：将应用进一步分解为微服务（分库）
Z轴：大数据量时，将服务分区（分表）
4、微服务的具体特征
官方的定义：
一、一些列的独立的服务共同组成系统
二、单独部署，跑在本身的进程中
三、每一个服务为独立的业务开发
四、分布式管理
五、很是强调隔离性
大概的标准：
一、分布式服务组成的系统
二、按照业务，而不是技术来划分组织
三、作有生命的产品而不是项目
四、强服务个体和弱通讯（ Smart endpoints and dumb pipes ）
五、自动化运维（ DevOps ）
六、高度容错性
七、快速演化和迭代
5、SOA和微服务的区别
1、SOA喜欢重用，微服务喜欢重写
SOA的主要目的是为了企业各个系统更加容易地融合在一块儿。 说到SOA不得不说ESB(EnterpriseService Bus)。 ESB是什么? 能够把ESB想象成一个链接全部企业级服务的脚手架。
经过service broker，它能够把不一样数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。 它还能够把一个服务
路由到另外一个服务上，也能够集中化管理业务逻辑，规则和验证等等。 它还有一个重要功能是消息队列和事件驱动的消息传递，好比把JMS服务转化成SOAP协议。 各服务间可能有
复杂的依赖关系。
微服务一般由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不必定必要。咱们向微服务迁移的时候一般从耦合度最低的模块或对扩展性要求最高的模块开始，
把它们一个一个剥离出来用敏捷地重写，能够尝试最新的技术和语言和框架，然 后单独布署。 它一般不依赖其余服务。微服务中经常使用的API Gateway的模式主要目的也不是重用代码，
而是减小客户端和服务间的往来。API gateway模式不等同与Facade模式，咱们可使用如future之类的调用，甚至返回不完整数据。
2、SOA喜欢水平服务，微服务喜欢垂直服务
SOA设计喜欢给服务分层(如Service Layers模式)。 咱们经常见到一个Entity服务层的设计，美其名曰Data Access Layer。 这种设计要求全部的服务都经过这个Entity服务层
来获取数据。 这种设计很是不灵活，好比每次数据层的改动均可能影响到全部业务层的服务。 而每一个微服务一般有它本身独立的data store。 咱们在拆分数据库时能够适当的作些
去范式化(denormalization)，让它不须要依赖其余服务的数据。
微服务一般是直接面对用户的，每一个微服务一般直接为用户提供某个功能。 相似的功能可能针对手机有一个服务，针对机顶盒是另一个服务。 在SOA设计模式中这种状况一般会用到
Multi-ChannelEndpoint的模式返回一个大而全的结果兼顾到全部的客户端的需求。
3、SOA喜欢自上而下，微服务喜欢自下而上
SOA架构在设计开始时会先定义好服务合同(service contract)。 它喜欢集中管理全部的服务，包括集中管理业务逻辑，数据，流程，schema，等等。 它使用Enterprise
Inventory和Service Composition等方法来集中管理服务。 SOA架构一般会预先把每一个模块服务接口都定义好。 模块系统间的通信必须遵照这些接口，各服务是针对他们的调用者。
SOA架构适用于TOGAF之类的架构方法论。
微服务则敏捷得多。只要用户用获得，就先把这个服务挖出来。而后针对性的，快速确认业务需求，快速开发迭代。
6、怎么具体实践微服务
要实际的应用微服务，须要解决一下四点问题：
一、客户端如何访问这些服务
二、每一个服务之间如何通讯
三、如此多的服务，如何实现？
四、服务挂了，如何解决？（备份方案，应急处理机制）
1、客户端如何访问这些服务
原来的Monolithic方式开发，全部的服务都是本地的，UI能够直接调用，如今按功能拆分红独立的服务，跑在独立的通常都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的？
后台有N个服务，前台就须要记住管理N个服务，一个服务下线/更新/升级，前台就要从新部署，这明显不服务咱们 拆分的理念，特别当前台是移动应用的时候，一般业务变化的节奏更快。
另外，N个小服务的调用也是一个不小的网络开销。还有通常微服务在系统内部，一般是无 状态的，用户登陆信息和权限管理最好有一个统一的地方维护管理（OAuth）。
因此，通常在后台N个服务和UI之间通常会一个代理或者叫API Gateway，他的做用包括：
① 提供统一服务入口，让微服务对前台透明
② 聚合后台的服务，节省流量，提高性能
③ 提供安全，过滤，流控等API管理功能
其实这个API Gateway能够有不少广义的实现办法，能够是一个软硬一体的盒子，也能够是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的做 用是为前台（一般是
移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。
用过Taobao Open Platform（淘宝开放平台）的就能很容易的体会，TAO就是这个API Gateway。
2、每一个服务之间如何通讯
全部的微服务都是独立的Java进程跑在独立的虚拟机上，因此服务间的通讯就是IPC（inter process communication），已经有不少成熟的方案。如今基本最通用的有两种方式：
同步调用：
①REST（JAX-RS，Spring Boot）
②RPC（Thrift, Dubbo）
异步消息调用(Kafka, Notify, MetaQ)
同步和异步的区别：
通常同步调用比较简单，一致性强，可是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个颇有意 思的话题。
通常REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的
SDK就能调用，因此相对使用的广一些。RPC也有本身的优势，传输协议更高效，安全更可控，特别在一个公司内部，若是有统一个 的开发规范和统一的服务框架时，
他的开发效率优点更明显些。就看各自的技术积累实际条件，本身的选择了。
而异步消息的方式在分布式系统中有特别普遍的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的
服务体验，继续干本身该干的活，不至于被后台性能拖慢。不过须要付出的代价是一致性的减弱，须要接受数据最终一致性；还有就是后台服务通常要 实现幂等性，由于消息
发送出于性能的考虑通常会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，若是公司内部没有技术积累，
对broker分布式管理也是一个很大的挑战。
3、如此多的服务，如何实现？
在微服务架构中，通常每个服务都是有多个拷贝，来作负载均衡。一个服务随时可能下线，也可能应对临时访问压力增长新的服务节点。服务之间如何相互感知？服务如何管理？
这就是服务发现的问题了。通常有两类作法，也各有优缺点。基本都是经过zookeeper等相似技术作服务注册信息的分布式管理。当服务上线时，服务提供者将本身的服务信息
注册到ZK（或相似框架），并经过心跳维持长连接，实时更新连接信息。服务调用者经过ZK寻址，根据可定制算法， 找到一个服务，还能够将服务信息缓存在本地以提升性能。
当服务下线时，ZK会发通知给服务客户端。
客户端作：优势是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护全部调用服务的地址，有技术难度，通常大公司都有成熟的内部框架支持，好比Dubbo。
服务端作：优势是简单，全部服务对于前台调用方透明，通常在小公司在云服务上部署的应用采用的比较多。
4、服务挂了，如何解决
前面提到，Monolithic方式开发一个很大的风险是，把全部鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。经过微服务拆分能下降这个风险，
不过若是没有特别的保障，结局确定是噩梦。因此当咱们的系统是由一系列的服务调用链组成的时候，咱们必须确保任一环节出问题都不至于影响总体链路。相应的手段有不少：
①重试机制
②限流
③熔断机制
④负载均衡
⑤降级（本地缓存）
这些方法基本都很明确通用，好比Netflix的Hystrix：https://github.com/Netflix/Hystrix
7、常见的设计模式和应用
有一个图很是好的总结微服务架构须要考虑的问题，包括：
一、API Gateway
二、服务间调用
三、服务发现
四、服务容错
五、服务部署
六、数据调用
六种常见的微服务架构设计模式：
1、聚合器微服务设计模式
这是一种最多见也最简单的设计模式：
聚合器调用多个服务实现应用程序所需的功能。它能够是一个简单的Web页面，将检索到的数据进行处理展现。它也能够是一个更高层次的组合微服务，对检索到的数据增长业务逻辑后进一步
发布成一个新的微服务，这符合DRY原则。另外，每一个服务都有本身的缓存和数据库。若是聚合器是一个组合服务，那么它也有本身的缓存和数据库。聚合器能够沿X轴和Z轴独立扩展。
2、代理微服务设计模式
这是聚合模式的一个变种，以下图所示：
在这种状况下，客户端并不聚合数据，但会根据业务需求的差异调用不一样的微服务。代理能够仅仅委派请求，也能够进行数据转换工做。
3、链式微服务设计模式
这种模式在接收到请求后会产生一个通过合并的响应，以下图所示：
在这种状况下，服务A接收到请求后会与服务B进行通讯，相似地，服务B会同服务C进行通讯。全部服务都使用同步消息传递。在整个链式调用完成以前，客户端会一直阻塞。
所以，服务调用链不宜过长，以避免客户端长时间等待。
四、分支微服务设计模式
这种模式是聚合器模式的扩展，容许同时调用两个微服务链，以下图所示：
五、数据共享微服务设计模式
自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithic application）”时，SQL数据库反规范化可能会致使数据重复和不一致。
所以，在单体应用到微服务架构的过渡阶段，可使用这种设计模式，以下图所示：
在这种状况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才能够。对于基于微服务的新建应用程序而言，这是一种反模式。
6、异步消息传递微服务设计模式
虽然REST设计模式很是流行，但它是同步的，会形成阻塞。所以部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，以下图所示：
8、优势和缺点
1、微服务的优势：
关键点：复杂度可控，独立按需扩展，技术选型灵活，容错，可用性高
①它解决了复杂性的问题。它会将一种怪异的总体应用程序分解成一组服务。虽然功能总量 不变，但应用程序已分解为可管理的块或服务。每一个服务都以RPC或消息驱动的API的
形式定义了一个明确的边界；Microservice架构模式实现了一个模块化水平。
②这种架构使每一个服务都可以由专一于该服务的团队独立开发。开发人员能够自由选择任何有用的技术，只要该服务符合API合同。固然，大多数组织都但愿避免彻底无政府状态并
限制技术选择。然而，这种自由意味着开发人员再也不有义务使用在新项目开始时存在的可能过期的技术。在编写新服务时，他们能够选择使用当前的技术。此外，因为服务相对较小，
所以使用当前技术重写旧服务变得可行。
③Microservice架构模式使每一个微服务都能独立部署。开发人员不须要协调部署本地服务的变动。这些变化能够在测试后尽快部署。例如，UI团队能够执行A | B测试，并快速迭代
UI更改。Microservice架构模式使连续部署成为可能。
④Microservice架构模式使每一个服务均可以独立调整。您能够仅部署知足其容量和可用性限制的每一个服务的实例数。此外，您可使用最符合服务资源要求的硬件。
2、微服务的缺点
关键点（挑战）：多服务运维难度，系统部署依赖，服务间通讯成本，数据一致性，系统集成测试，重复工做，性能监控等
①一个缺点是名称自己。术语microservice过分强调服务规模。但重要的是要记住，这是一种手段，而不是主要目标。微服务的目标是充分分解应用程序，以便于敏捷应用程序开发和部署。
②微服务器的另外一个主要缺点是分布式系统而产生的复杂性。开发人员须要选择和实现基于消息传递或RPC的进程间通讯机制。此外，他们还必须编写代码来处理部分故障，
由于请求的目的地可能很慢或不可用。
③微服务器的另外一个挑战是分区数据库架构。更新多个业务实体的业务交易是至关广泛的。可是，在基于微服务器的应用程序中，您须要更新不一样服务所拥有的多个数据库。使用分布式事务
一般不是一个选择，而不只仅是由于CAP定理。许多今天高度可扩展的NoSQL数据库都不支持它们。你最终不得不使用最终的一致性方法，这对开发人员来讲更具挑战性。
④测试微服务应用程序也更复杂。服务相似的测试类将须要启动该服务及其所依赖的任何服务（或至少为这些服务配置存根）。再次，重要的是不要低估这样作的复杂性。
⑤Microservice架构模式的另外一个主要挑战是实现跨越多个服务的更改。例如，咱们假设您正在实施一个须要更改服务A，B和C的故事，其中A取决于B和B取决于C.在单片应用程序中，
您能够简单地更改相应的模块，整合更改，并一次性部署。相比之下，在Microservice架构模式中，您须要仔细规划和协调对每一个服务的更改。例如，您须要更新服务C，而后更新服务B，
而后再维修A.幸运的是，大多数更改通常仅影响一个服务，而须要协调的多服务变动相对较少。
⑥部署基于微服务的应用程序也更复杂。单一应用程序简单地部署在传统负载平衡器后面的一组相同的服务器上。每一个应用程序实例都配置有基础架构服务（如数据库和消息代理）
的位置（主机和端口）。相比之下，微服务应用一般由大量服务组成。例如，每一个服务将有多个运行时实例。更多的移动部件需要进行配置，部署，扩展和监控。此外，您还须要实现服务
发现机制，使服务可以发现须要与之通讯的任何其余服务的位置（主机和端口）。传统的基于故障单和手动操做的方法没法扩展到这种复杂程度。所以，成功部署微服务应用程序须要
开发人员更好地控制部署方法，并实现高水平的自动化。
9、思考：意识的转变
微服务对咱们的思考，更多的是思惟上的转变。对于微服务架构：技术上不是问题，意识比工具重要。
关于微服务的几点设计出发点：
一、应用程序的核心是业务逻辑，按照业务或客户需求组织资源（这是最难的）
二、作有生命的产品，而不是项目
三、头狼战队，全栈化
四、后台服务贯彻Single Responsibility Principle（单一职责原则）
五、VM->Docker （to PE）
六、DevOps (to PE)
同时，对于开发同窗，有这么多的中间件和强大的PE支持当然是好事，咱们也须要深刻去了解这些中间件背后的原理，知其然知其因此然，在有限的技术资源如何经过开源技术实施微服务？
最后，通常提到微服务都离不开DevOps和Docker，理解微服务架构是核心，devops和docker是工具，是手段。
10、参考资料和推荐阅读：
http://kb.cnblogs.com/page/520922/
http://www.infoq.com/cn/articles/seven-uservices-antipatterns
http://www.csdn.net/article/2015-08-07/2825412
http://blog.csdn.net/mindfloating/article/details/45740573