引言
- 微服务是一种服务间松耦合的、每个服务之间高度自治并且使用轻量级协议进行通信的可持续集成部署的分布式架构体系
- 那么，微服务架构又与其它架构有何区别?
单体架构（Monolithic）
- 单体架构是最简单的软件架构，常用于传统的应用软件开发以及传统 Web 应用，适用于用户业务不复杂、访问量较小的时候，甚至可以将应用服务、数据库、文件服务器部署在一台服务器上（相信很多人都这么干过，_）
- (MVC)三层设计模型（表示层、业务逻辑处理层、数据访问层）：
- 表示层：通常理解为用于和用户交互的视图层；
- 业务逻辑处理层：用户提交请求，经过业务逻辑层处理后，对用户请求作出响应；
- 数据库访问层：主要用于操作数据库。
- 缺点：
- 随着业务越来越复杂，单体应用代码量急剧膨胀，最终导致代码可 读性、可维护性和可扩展性得不到保证；
- 随着用户访问量增加，单体应用的并发能力有限；
- 随着系统代码量的剧增，当修改应用程序或者新增需求时，测试难度成指数级增长；
- 部署效率低下（即使是一个很小的改动，也需要将所有机器上的应用全部部署一遍）， 增加运维复杂度；
- 技术选型单一。
留白
- 在某个阳光明媚、风和日丽的日子里，使用单体架构发现很难推进需求的开发、以及日积月累的技术债，终于爆发了，很多企业开始做单体服务的拆分，拆分的方式一般有水平拆分和垂直拆分，逐渐演变出了SOA（Service Oriented Architecture）架构， SOA 一出世，便被赋予了重大使命…
SOA 架构（Service Oriented Architecture）
- SOA是个什么鬼？
- SOA 是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA 可以看作是 B/S 模型、XML（标准通用标记语言的子集）/Web Service 技术之后的自然延伸。
- 你说了这么多，但我还是不知道SOA是个什么鬼啊？你能说的通熟易懂点儿么？
- 单体服务如果相当于一个快餐店，老板（堪称全能）又要负责收银结算，又要负责做汉堡，又要负责端盘子，又要负责打扫，用户来了后，老板从前到后负责到底（累死个人哟）。SOA 相当于老板按需招聘了些许服务员，有职责分工，收银员负责收银，厨师负责做汉堡，保洁阿姨负责打扫（老板没事到处转悠转悠，晒晒太阳什么的，解放自己，坐等数票票）等，所有服务员需要用同一种语言交流，方便工作协调。
- 有什么优点吗？
- 把模块（即服务）拆分，使用接口通信，降低模块之间的耦合度；
- 把项目拆分成若干个子项目，不同的团队负责不同的子项目；
- 增加功能时只需要再增加一个子项目，调用其它系统的接口就可以；
- 可以灵活的进行分布式部署。
- 说了这么多优点，不可能一点缺点都没有吧，不要王婆卖瓜自卖自夸哈…
- 和单体架构相比，增加了系统复杂度，系统整体性能有较大影响;
- 多服务数据通信协议之间转换过程复杂，容易造成 ESB（Enterprise Service Bus）性能瓶颈。
SOA架构图
- ESB 架构
- 简单说下， ESB 就像一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通;
- 举个栗子: 当业务越来越复杂，调用关系乱成一团， ESB 现身梳理了梳理各种应用系统的复杂关系，调用关系就会清晰很多（具体参照图片）
ESB架构图(简)
总结
balabala… 说了一坨乱七八糟的东西之后，我们说一说SOA 到底解决了我们的那些问题：
系统间的集成【有序】
站在系统角度， 首先要解决的是各个系统之间的通信问题，
目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范，比如
ESB、以及技术规范、服务管理规范
系统的服务化【复用】
站在功能角度， 提出问题：
那么多业务就没有通用的吗？如果有，怎么抽象出通用业务逻辑，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;
业务的服务化【高效】
站在全局角度，前面两步都是从技术层面来解决系统调用、系统功能复用的问题，我们需要在业务层面，目的是封装某一业务单元为服务，
微服务架构（MicroServices）
微服务的概念是 Martin Flower 在2014年写的一篇论文《MicroServices》中提出来的
主要特点
- 每个服务按照业务划分；
- 服务之间通过轻量级 API 调用；
- 可以使用不同语言开发；
- 可以使用不同的数据存储技术；
- 可独立部署，服务之间互相不影响；
- 可针对用户访问流量大的服务单独扩展，从而能够节约资源；
- 管理自动化。
主要挑战
- 微服务粒度大小难以划分，需要设计人员对业务有很好的掌握；
- 分布式复杂性，主要体现在分布式事务、网络延迟、系统容错等问题解决难度较大；
- 微服务之间通信成本较高，对微服务之间网络稳定性、通信速度要求较高；
- 由于微服务数量较大，运维人员运维、部署有较大的挑战
微服务架构和 SOA 架构
微服务架构和 SOA 架构非常类似,微服务是 SOA
的升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。
组件表示的就是一个可以独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。若我们把
PC 中的各个组件以服务的方式构 建，那么这台 PC
只需要维护主板（可以理解为ESB）和一些必要的外部设备就可以。CPU、内存、硬盘等都是以组件方式提供服务，例如PC 需要调用 CPU
做计算处理，只需知道 CPU 这个组件的地址就可以了。
综上，按照我们自己的理解，可以抽检出几个关键词来表达对微服务的理解与开展
微服务的理解与开展
松耦合
DDD（领域驱动设计）的思想进行设计领域模型，服务间尽量减少同步的调用，多使用消息的方式让服务间的领域事件来进行解耦
轻量级协议
更倾向于使用 Restful 风格的 API，轻量级的协议可以很好地支持跨语言开发的服务，并且Restful 风格的API 便于理解
高度自治和持续集成
微服务可以很好得和容器技术结合，容器技术比微服务出现得晚，但是容器技术的出现让微服务的实施更加简
便，目前 Docker 已经成为很多微服务实践的基础容器， 因为容器的特色，所以一台机器上可以部署几十个、
几百个不同的微服务。如果某个微服务流量压力比其他微服务大，可以在不增加机器的情况下，在一台机器上
多分配一些该微服务的容器实例。同时，因为 Docker 的容器编排社区日渐成熟，类似 Mesos、Kubernetes 及
Docker 官方提供的 Swarm 都可以作为持续集成部署的技术选择
架构的演进
- 方向
- 轻量级、灵活，甚至于 Serverless（无服务）架构
- 单体 ——> 分层 ——> 面向服务 ——> 微服务 ——> Serverless（无服务）
微服务&分布式关系
- 微服务架构属于分布式系统吗？那必须得是啊…
- 作为一个微服务，给其他人使用，不得保证高可用啊，然后分布式就自个儿蹦出来了…
- 微服务的分布式不仅仅是容器应用层面的分布式，其为了高度自治，底层的存储体系也应该互相独立，并且也不是所有的微服务都需要持久化的存储服务
微服务&分布式理解
- 怎样理解微服务中的分布式？以公司来举例说明，一个公司内，多个部门，各司其职，相互配合，各自占据一块区域，有些东西呢，只有该部门的人能使用，而有些呢，所有人都会使用，有些呢，自己部门没有，其它部门却拥有，既有专属资源，又有共享资源，同时共享资源还得考虑各种使用要求什么的，大抵是这样子
- 微服务的分布式不仅仅是容器应用层面的分布式，其为了高度自治，底层的存储体系也应该互相独立，并且也不是所有的微服务都需要持久化的存储服务
- 微服务中的分布式场景除了服务本身需要有服务发现、负载均衡，微服务依赖的底层存储也会有分布式的场景：为了高可用性和性能需要处理数据库的复制、分区，并且在存储的分库情况下，微服务需要能保证分布式事务的一致性。
如有问题，请留言或及时联系，感谢阅读
– end –
