微服务生态总结

1.SOA

SOA = Service-Oriented Architecture，SOA 中文定义是面向服务架构。

SOA首先要关注的是如何根据业务划分子系统，然后是子系统间如何协作，最后才是子系统内部实现。SOA设计可以很有效支持前面两步，在SOA体系里，每个子系统是独立的服务，服务接口体现子系统协作关系，至于子系统内部，直接作为黑盒子处理。

所以对于复杂系统，首先采用SOA垂直切分子系统(业务划分子系统)，然后使用分层设计水平切分单个子系统，服务化把传统的分层设计往前更推进一步。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。是集成多个较大组件（一般是应用）的一种机制，它们将整体构成一个彼此协作的套件。一般来说，每个组件会从始至终执行一块完整的业务逻辑，通常包括完成整体大action所需的各种具体任务与功能。组件一般都是松耦合的，但这并非SOA架构模式的要求。

尽管没有严格要求，SOA一般使用某种集中式管理，比如审查委员会、主架构师或架构委员会来严格定义每个系统组件应当做什么，如何执行。相同类型的功能可能会按需在多个组件中分别定义与记录，而每个组件所使用的语言与工具集有可能是集中确定与统一的，也可能不是。SOA可能使用任何类型的SDLC、组织架构或符合这种管理的开发模型；敏捷、瀑布、看板管理或者一些组合形式都是可用而不违反SOA原则的。

在 SOA 程序中，公开服务旨在公开每个业务功能，以便服务可得到尽可能多的重用。这样，每个新项目就不需要经历再次与后端系统执行集成的痛苦。典型的用户是尝试将全新的用户界面放在旧记录系统上的内部应用程序。在这样做时，集成非常困难，而且会花费很大一部分的 IT 项目预算。如果可以通过可重用的接口公开公司的所有核心功能，就可以大大削减项目成本。SOA 旨在节省成本，而不是创造新收入。

此外，现代化的DevOps和云部署对SOA当然很有效，在这种系统中缩减组件数量并非必需。但在这些系统中，就算在最好的情况下，一些较大的组件也可能太过复杂而难以实现自动化，在最坏的情况下甚至完全无法实现。

举个例子，自动化部署的一个标准可能得需要100%通过一套自动化测试。这将确保现有的功能在新版本中仍旧可用（没有回归），而新功能也按照预期实现。随着功能交互越来越多，看似不相关的开发工作意外破坏现有功能某些方面的可能性有所增加。

此外一些测试可能很敏感，由于坏境或网络因素而出现失败个例。在100个测试案例中，5%的随机测试出现1%的失败率不会对普通发布造成大的阻碍。而在成千上万的测试中，同样的几率可能会造成较大影响，很多时候会造成至少一个随机故障。因此，即便要发布的版本没有什么实际的错误，也会因为无法通过这条标准而无法部署。

特征

• 面向服务（ Service-Oriented ）
• 松耦合（Loose-Coupling）
• 模块化（Modular）
• 分布式计算（Distributed Computing）
• 平台无关性（Independent Platform）
• 集中管理（Center Government）

技术

• Web Services
  Web Services 技术演进的目的在于解决分布式计算中，统一异构系统的服务调用的通讯协议。前期的Web Services有XML-PRC、WSDL、SOAP等技术，不但解决了Windows平台COM+以及Java 平台RMI无法跨平台的问题，而且使用了可读性强的本文协议替代了复杂的二进制协议，如CORBA技术。现代的WebServices 技术主要代表有REST等。
• Message Queue
  Message Queue 技术设计的目的主要有两个方面，从架构上来说，消息队列服务帮助系统之间依赖关系解耦；从技术上来看，消息队列为系统提供异步处理的能力，解决了并发同步调用导致资源消耗过集中和过快等问题，将上下游系统的数据结构提供了统一的传输介质。
• ESB
  ESB 则是 SOA 集大成实现。

2.微服务

微服务是一种架构设计模式。而架构则是“技”的实现与“术”的策略相辅相成。“术”的策略需要分析使用场景，进行合理地划分业务边界，实现“业以类聚”，然而“技”的实现则通过特定的技术在实现业务逻辑之时，更多的考虑实现过程中的效率性、测试的便利性、维护的可持续性，达到“技以群分”的目的。微服务是一种细粒度的SOA，细粒度更多的体现在“取其精华，去其糟粕”。在微服务架构中，业务逻辑被拆分成一系列小而松散耦合的分布式组件，共同构成了较大的应用。每个组件都被称为微服务，而每个微服务都在整体架构中执行着单独的任务，或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用，以执行较大应用需要完成的具体任务。

微服务与单体应用的区别

与微服务相对应的是单体式应用（即Monolithic Application）模式，

它将一个应用程序以一个业务需求视为一个整体，所有功能都放入一个应用程序中执行。企业应用系统架构通常可分为三层：前端表示层（即Web界面）、业务逻辑层、持久层，单体式应用模式通常将这三层封装成单个的Web应用程序。比如，Web应用程序发展的早期，大部分Web工程是将所有的功能模块（service side）打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包，或者是分层结构，如表现层/应用层/领域层/数据层，这主要是水平切分的思想。其他语言（Ruby，Python或者C++）写的程序也有类似的情况。

Monolithic比较适合小项目，优点是：

• 开发简单直接，集中式管理
• 基本不会重复开发
• 功能都在本地，没有分布式的管理开销和调用开销

它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
• 代码维护难：代码功能耦合在一起，新人不知道何从下手
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
• 扩展性不够：无法满足高并发情况下的业务需求

如下图所示：传统的web开发方式，所有的功能打包在一个WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了DO/DAO，Service，UI等所有逻辑。

而微服务架构则反其道而行之，借由很多小型的服务，共同组合成完整的服务程序。微服务所设计的每个微服务都要非常容易被抛弃、被替换。拥抱不断变化的业务，快读迭代开发。微服务设计目标是降低系统复杂度，提高开发生产力，是适合敏捷方法快速建立持续改进的系统，例如互联网应用。

微服务架构云化方案一般融合Docker和DevOps技术，解决租户隔离和统一开发平台的需求。

例如以建设企业办公楼为例，微服务借助DevOps工具，使用服务化的建筑预制件快速搭建需要的办公楼（室），其中内含水电等都是独立的。

微服务与SOA的区别

其实服务化架构（SOA）已经可以解决大部分企业的需求了，那么我们为什么要研究微服务呢？先说说它们的区别：

• 微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务
• 微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
• 微服务强调每个微服务都有自己独立的运行空间，包括数据库资源
• 微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行
• 微服务的切分粒度会更小，微服务是一种细粒度的SOA
• 微服务与SOA相比，更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。
• SOA将应用程序的功能公开为更容易访问的服务接口，使得在下一代应用程序中使用它们的数据和逻辑变得更容易。SOA 似乎拥有 企业范围，应用程序在该范围内彼此通信。SOA 通过应用程序之间的标准化接口来公开服务。微服务架构似乎拥有 应用程序范围，仅关注一个应用程序内的结构和组件。

微服务与SOA有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。但是两种架构背后的意图是不同的：SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。

下面进一步解释上表所述的不同之处：

• 开发方面 - 在这两种体系结构中，可以使用不同的编程语言和工具开发服务，从而将技术多样性带入开发团队。开发可以在多个团队中组织，但是在SOA中，每个团队都需要了解常见的通信机制。另一方面，使用微服务，服务可以独立于其他服务运行和部署。因此，频繁部署新版本的微服务或独立扩展服务会更容易。您可以在这里进一步阅读有关微服务的这些好处。

• “上下文边界” - SOA鼓励组件的共享，而微服务尝试通过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。由于SOA依靠多个服务来完成业务请求，构建在SOA上的系统可能比微服务要慢。

• 通信 - 在SOA中，ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信，如果其中一个服务变慢，可能会阻塞ESB并请求该服务。另一方面，微服务在容错方面要好得多。例如，如果一个微服务存在内存错误，那么只有该微服务会受到影响。所有其他微服务将继续定期处理请求。

• 互操作性 - SOA通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。因此，如果您想要在异构环境中使用不同协议来集成多个系统，则需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问，那么微服务对您来说是一个更好的选择。

• 大小Size - 最后一点但并非最不重要的一点，SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度，意味着它们必须比SOA架构的服务往往要小得多。微服务中的服务组件通常有一个单一的目的，他们做得很好。另一方面，在SOA服务中通​​常包含更多的业务功能，并且通常将它们实现为完整的子系统。

实例对比——建立购物车

我们来看一个在线购物网站。这个网站会有一些不同的功能，比如产品目录、用户帐号还有购物车等等。

使用SOA的开发公司一般会将购物网站拆分成主要的业务逻辑组，并将每个部分作为独立应用分别开发，最后集成到一起。

举个例子，整个购物车及其所有功能是由一大群人所开发的一个应用，他们需要了解整个购物车的工作机制，以便能够修改。在这个应用中，是代码负责显示物品、增加或移除购物车商品、查看库存、处理运费选项、处理税率计算、处理汇率、在更改时更新显示并将最终的订单细节发到用户邮箱里（还有其他等等）。用来显示购物车商品的代码包括在购物车应用中，可能与在浏览目录视图中用来显示商品名称的代码截然不同，从而造成需要维护的两套代码相似但不相同，还可能造成大应用UX上的某些不一致。

使用微服务架构的开发公司会将购物车切分成较小的任务导向服务。不再是购物车应用了，而可能是税率计算服务、添加/移除商品服务、运费服务、汇率服务和最终订单撰写服务。购物车功能可能也会用到一些常用的服务——它们会用在购物应用的很多地方，比如显示商品服务、显示产品图片服务、查看库存服务、用户支付偏好服务以及邮件服务。而“购物车”、“产品目录、“用户账户”之间并没有分界，通用代码被封装成各种服务，待需要时用在各种功能中。

为什么要微服务？

• 效率的需要
  应用进行微服务化后，规模和体积变得更加轻量级，在编译、打包、分发、部署等环节节约了时间，开发上效率提升。
• 质量的需要
  微服务应用面向持续集成友好，自动化编译、单元和集成测试用例执行和回归，提高应用整体质量。
• 稳定的需要
  当应用大而全时，往往牵一发而动全身，其中一个服务出现问题，整体受到牵动效应。整体稳定性得不到保证，因此，经过微服务化后，应用由原来的服务内部组装到服务自由组合，一旦关联服务存在问题，整体应用可以选择性地降级或熔断等措施，待问题服务恢复，一切照常执行。
• 运维的需要
  微服务应用具备自动化编译、打包、分发、部署和运维的能力。传统的应用不但需要开发、还需要测试和运维人员，微服务应用实现后，将理想化的全栈（Full-Stack）工程师变为可能。
• 成长的需要
  微服务能够更好，更快地适配新技术，比如目前流行的Apache Kafka。而工程人员需要接触新的技术，为未来可能的技术选型做好准备。我的建议在一些不那么重要的微服务应用中，可以尝试一些新的技术，在其提供的功能与实际需要之间，找到一些自己的理解，也是自我成长的需要。
• 简化开发的需要
  每个微服务的代码库与相关工具集都很有限；开发者无需再去了解庞大而复杂的系统，只需理解自己所做的那部分微服务相关子集，便能贡献生产力。由于无需考虑应用的现有部分使用了什么语言或工具集，或者较大应用的其他开发者是否了解这些语言和工具，只需使用当前任务最趁手的工具，因此微服务开发起来非常迅速。

我个人理解，Microservice是SOA的传承，但一个最本质的区别就在于Smart endpoints and dumb pipes，或者说是真正的分布式的、去中心化的。Smart endpoints and dumb pipes本质就是去ESB，把所有的“思考”逻辑包括路由、消息解析等放在服务内部（Smart endpoints），去掉一个大一统的ESB，服务间轻（dumb pipes）通信，是比SOA更彻底的拆分。

为什么不必微服务？

• 场景单一
  当应用的场景单一时，没有必要非得微服务，因为它本身就是微服务，例如一些静态的通告页面。
• 逻辑简单
  当应用逻辑简单时，同样也违背了微服务的初衷，因为微服务是为了解决复杂业务逻辑而衍生，因此这种情况下也不必实施微服务。
• 业务渐逝
  首先，我解释一下“渐逝”，也就是逐渐消逝的意思。当应用所关注的业务趋于消逝状态时，尽管有实施的空间，但无实施的必要。因为这样的应用随时可能不复存在，好比没有必要去对BB机或者短信业务大张旗鼓的重构一般。
• “老成持重”
  老成持重的原意是形容人做事情老练和沉稳。这里我引用了这个成语，是为了方便记忆，需要将其拆开，单独解释。
  “老”是指年老的应用，多久算得上年老呢？个人经验，应用服役年龄超过三年以上。
  “成”则表示应用的规模已成形，业务上几乎不再变化，比如通知应用。
  “持”说明应用的场景还将持续较长时间。
  “重”表示应用所处的位置举足轻重，不能随时重构，比如交易应用。
  当应用符合其中一条以上的特征时，该应用不必实行微服务。
• 技术盲从
  微服务并不适合每个应用程序。目前微服务社区中的一种悖论是，让新的、相对简单的、具有高度凝聚性数据模型的应用程序采用微服务的概念，这样做不会获得任何优势。另外，将一个复杂的现有应用程序重构到微服务架构中是一项繁重的工作。如果不是在旧版或新式应用程序上，您会何时使用微服务？一种 建议是，在以传统方式编写的应用程序达到复杂性的拐点之前，不要使用微服务。但是，要让此方法发挥作用，则需要从一开始就编写一个适当构建的应用程序，并选择在正确的时刻执行过渡。
  这一点是我最为关注，也是最担心朋友触犯的。我们同为工程人员，对技术的追求毋容置疑，可是千万不能因为技术而技术，新的技术推出或是解决现有问题，或是提供便利性，可是也有夸大其词的成分。理性地评估和谨慎地实施，更是我们更要关注的地方。技术困难挑战聪明才智，理智对待则考验情绪控制。

客户端如何访问这些服务？

原来的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。

服务之间如何通信？

因为所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通信就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式。这几种方式，展开来讲都可以写本书，而且大家一般都比较熟悉细节了，就不展开讲了。

• 同步调用
  
  • REST（JAX-RS）
  • RPC（Dubbo）
• 异步消息调用(Kafka, Notify, MetaQ)
  

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意思的话题。一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一的开发规范和统一的服务框架时，他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。

而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

如何实践

• 为了充分利用速度优势，让小团队开发成为可能，团队需要自主权；他们必须能迅速作出决定，避免过度监管。要想支持这一点，工作团队应当包括所有相关人员，从产品经理到发布运行人员。由于微服务组件是松散耦合并通过API通讯的，各方在大多决定时拥有高度自主权并不会影响应用的整体功能。只要微服务能发布API，并能用这些API执行所需的功能，整体系统就能运作良好。

• 由于在一个微服务架构中有许多独立的组件，在弹性网络（比如公共或私有云）上使用现代化的DevOps对于确保整体系统在大多数情况下正常运转就显得尤为重要。特别是像与额外实例的自动部署相关联的健康与负载自动监控（为了尽可能减少未充分利用的实例）这样的东西在很多情况下就变得至关重要。

这么多服务，怎么找?

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

• 客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。
• 服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。
  

这么多服务，服务挂了怎么办？

前面提到，Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。我们刚遇到一个线上故障就是一个很不起眼的SQL计数功能，在访问量上升时，导致数据库load彪高，影响了所在应用的性能，从而影响所有调用这个应用服务的前台应用。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

• 重试机制
• 限流
• 熔断机制
• 负载均衡
• 降级（本地缓存）

这些方法基本上都很明确通用，就不详细说明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

微服务的困境

微服务的优点和缺点（或者说挑战）一样明显。

• 优点

  • 开发简单
  • 技术栈灵活
  • 服务独立无依赖
  • 独立按需扩展
  • 可用性高

• 缺点（挑战）

  • 多服务运维难度
  • 系统部署依赖
  • 服务间通信成本
  • 数据一致性
  • 系统集成测试
  • 重复工作
  • 性能监控

由大量微型服务组合而成的微服务应用，其特征是每一个微服务都是独立执行，且每个服务能够各自扩展，甚至可以用不同的编程语言来开发同一个业务所需的各个微服务。微服务架构虽然具备弹性、可扩展性的优点，但它也带来了管理大量服务的复杂性，特别是微型服务的数量极多的情况更为明显。要构建分布式微服务架构的应用，往往只有大型互联网公司才有能力完成。

这里有一个图非常好的总结微服务架构需要考虑的问题，包括

• API Gateway
• 服务间调用
• 服务发现
• 服务容错
• 服务部署
• 数据调用

微服务的新生

随着容器技术的成熟，过去实现难度很高的微服务架构，开始“飞入寻常百姓家”。容器技术可以将各种微型程序打包成可独立运行的映像，发布到任何可用的容器平台上执行。开发者只要将业务应用所需的所有功能程序打包成一个个的Docker映像，部署到各个容器中就能实现提供不同功能的微服务。这样开发者就可以通过同样的工具和技术来管理大量的微服务，而不用自己维护微服务架构技术。

https://mp.weixin.qq.com/s/8cC4Ewt6yPjnxdYxuNZlFQ
https://www.datawire.io/microservices-vs-soa/
http://geek.csdn.net/news/detail/51826
https://www.cnblogs.com/ynuo/p/5913955.html
http://blog.csdn.net/wangtaomtk/article/details/51811069
https://yq.aliyun.com/articles/2764
http://blog.csdn.net/chszs/article/details/78515231