摘录于网上，文章出处不详
一、微服务架构介绍
微服务架构是一种架构概念，通过将功能分解到各个离散的服务中以实现对解决方案的解耦，从而降低系统的耦合性。 可以将其看作是在架构层次而
非获取服务的类上应用很多solid原则。 围绕业务领域组件来创建应用，这些应用可独立开发、管理和迭代。在分散的组件中使用云架构和平台化部署
管理和服务功能，使产品交付变得更加简单
常见的系统架构遵循的三个标准和业务驱动力
1、提高敏捷性： 及时响应业务需求，促进企业发展
2、提升用户体验： 提升用户体验，减少用户流失
3、降低成本： 降低增加产品、客户或业务方案的成本
二、微服务的特征
1、分布式服务组成的系统
2、按照业务，而不是技术来划分组织
3、强服务个体和弱通信
4、自动化运维
5、高度容错性
6、快速演化和迭代
三、SOA和微服务的区别
1、SOA喜欢重用，微服务喜欢重写
SOA的主要目的是为了企业各个系统更加容易融合在一起。 各服务间可能有复杂的依赖关系
微服务通常由重写一个模块开始。要把整个应用重写是有很大的风险的，也不一定必要。 可以先从耦合度最低的
模块或对扩展性要求最高的模块开始。 把它们一个一个剥离出来做敏捷地重写，可以尝试最新的技术和语言和框架，
然后单独部署。 微服务中常用法人API getaway 的模式主要目的也不是重用代码， 而是减少客户端和服务间的往来。
API geteway的模式不等同facade模式，我们可以使用如future之类的调用，甚至返回不完整数据
2、SOA水平服务，微服务垂直服务
SOA设计给服务分层。 常见的例子就是一个entity服务层的设计。这种设计要求所有的服务都通过这个entity服务层来
获取数据。这样的设计非常不灵活，比如每次数据层的改动可能影响到所有业务层的服务。 而每个微服务通常有自己
独立的data store。 我们在拆分数据库时可以适当做些去范式化，让其不依赖其他服务的数据
微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。类似的功能可能针对手机有一个服务，针对
机顶盒是另外一个服务。
3、SOA自上而下， 微服务自下而上
SOA架构在设计开始时先定义好服务合同。 集中管理所有的服务，包括集中管理业务逻辑，数据、流程、schema。使用
enterprise inventory和service composition等方法来集中管理服务。 SOA架构通常会预先把每个模块服务借口都定义好。
模块系统之间的通讯遵守这些接口，各服务是针对他们的调用者。
四、微服务的实践
1、客户端如何访问这些服务
原来的monolithic方式开发，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般
都在独立的虚拟机上的Java进程了。 那么客户端UI如何访问？ 后台有N个服务，前台就需要记住管理N个服务，一个服务
下线、更新、升级，前台就需要重新部署，这不符合我们拆分的理念。 另外，N个小服务的调用也是一个不小的网络开销。
还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理。 所以，一般
在后台N个服务和UI之间一般会 有一个代理或者叫API gateway，其作用包括：
1） 提供统一服务入口，让微服务对前台透明
2） 聚合后台的服务，节省流量，提升性能
3） 提供安全、过滤、流控等API管理功能
其实这个API gateway 可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单MVC框架，甚至是一个node.js
的服务端，他们最重要的作用是为前台提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API gateway也有
可能成为单点故障或性能的瓶颈
2、每个服务之间如何通信
所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通信就是IPC。现在基本最通用的有两种方式
1） rest （jax-rs springboot）
2) rpc (thrift， dubbo)
异步消息调用（kafka notify metaQ）
同步和异步的区别
一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。 一般rest基于HTTP，更容易
实现，更容易被接受，服务端实现技术也更灵活，各个语言都支持，也能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就
能调用，所以相对使用的广一些。 RPC也有自己的缺点，传输协议更高效，安全更可控。
异步消息的方式在分布式系统中有广泛的应用，既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，
同时能保证调用方服务体验。 㘝需要付出一致性的减弱，需要接受数据最终一致性；还有后台服务一般要实现幂等性，因为消息发送出于
性能的考虑一般会右重复，最后就是必须引入一个独立的broker，对broker分布式管理也是很大的挑战
3、如何实现这样多的服务
在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡、一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务
之间如何相互感知？ 服务如何管理？ 这就是服务发现的问题。一般有两类做法。基本都是通过zookeeper等类似技术做服务注册信息的分布式
管理。当服务上线时，服务提供者将自己的服务信息注册到ZK，并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可
定制算法，找到一个服务，还可以将服务信息换成在本地以提高性能。 当服务下线时时，ZK会发通知服务客户端。
4、服务挂了，如何解决
当系统由一系列的服务调用链组成的时候，必须确保任一环节出现问题都不至于影响整体链路。 相应的手段有很多
1） 重试机制 2） 限流 3）熔断机制 4） 负载均衡 5）降级
六种常见的微服务架构设计模式
1、聚合器微服务设计模式
聚合器调用多个服务实现应用程序所需的功能。 它可以是一个简单的web页面，将检索到的数据进行处理展示。 它也可以是
一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。 另外，每个
服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。
2、代理微服务设计模式
客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
3、链式微服务设计模式
服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用
完成之前，客户端会一直阻塞。 因此，服务调用链不宜过长，以免客户端长时间等待。
4、分支微服务设计模式
这种模式是聚合器模式的扩展，允许同时调用两个微服务链。
5、数据共享微服务设计模式
自治是微服务的设计原则之一，就是说微服务是全栈式服务。 在这种情况下，部分微服务可能会共享缓存和数据存储。不过，
这只有在两个服务之间存在强耦合关系时才可以
6、异步消息传递微服务设计模式
rest设计模式是同步，会造成阻塞。 因此部分基于微服务的架构可能会选择使用消息队列代替rest请求/响应