什么是微服务？就目前而言，对于微服务业界并没有一个统一的、标准的定义。但通常在其而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。
总结了以下几点：
①小服务
小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。
②进程独立
每一组服务都是独立运行的，可能我这个服务运行在 Tomcat 容器，而
另一个服务运行在 Jetty 上。可以通过进程方式，不断的横向扩展整
个服务。
③通信
过去的协议都是很重的，就像 ESB，就像 SOAP，轻通信，这意味着相
比过去更智能更轻量的服务相互调用，就所谓 smart endpoints and
dumb pipes。
这些 Endpoint 都是解耦的，完成一个业务通信调用串起这些 Micro
Service 就像是 Linux 系统中通过管道串起一系列命令业务。
过去的业务，我们通常会考虑各种各样的依赖关系，考虑系统耦合带来
的问题。微服务，可以让开发者更专注于业务的逻辑开发。
④部署
不止业务要独立，部署也要独立。不过这也意味着，传统的开发流程会
出现一定程度的改变，开发的适合也要有一定的运维职责。
⑤管理
传统的企业级 SOA 服务往往很大，不易于管理，耦合性高，团队开发
成本比较大。
微服务，可以让团队各思其政的选择技术实现，不同的 Service 可以
根据各自的需要选择不同的技术栈来实现其业务逻辑。
微服务的利与弊
?优点是每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求。
?开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
?微服务能够被小团队单独开发，这个小团队是 2 到 5 人的开发人员组成。?微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
?微服务能使用不同的语言开发。
?易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如 Jenkins，Hudson，bamboo。
?微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。微服务允许你利用融合最新技术。
?微服务只是业务逻辑的代码，不会和 HTML，CSS 或其他界面组件混合。?每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
总的来说，微服务的优势，就是在于，面对大的系统，可以有效的减少复杂程度，使服务架构的逻辑更清晰明了。
但是这样也会带来很多问题，就譬如分布式环境下的数据一致性，测试的复杂性，运维的复杂性。
什么组织适合使用微服务？
微服务带了种种优点，种种弊端，那么什么组织适合使用微服务？
①墨菲定律（设计系统）和康威定律（系统划分）
设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。
看看下面的图片，再想想 Apple 的产品、微软的产品设计，就能形象
生动的理解这句话。
②架构演化
架构是不断演化出来的，微服务也是这样，当从各大科技公司，规模大
到一定程度，完全需要演化成更进一步管理的技术架构体系。
传统的团队，都是面向过程化的，产品想完了去找策划，策划完了找开发，接着顺着一步一步找。
我们做技术都是为了产品的，一旦过程出来了什么问题，回溯寻找问题会
非常耗时。
使用了微服务架构体系，团队组织方式需要转变成跨职能团队，即每个团队都有产品专家，策划专家，开发专家，运维专家，他们使用 API 方式发布他们的功能，而平台使用他们的功能发布产品。
微服务技术架构体系
下面分享一下大部分公司都使用的微服务技术架构体系：
服务发现
主流的服务发现，分为三种：
第一种，开发人员开发了程序以后，会找运维配一个域名，服务的话通过DNS 就能找到我们对应的服务。
缺点是，由于服务没有负载均衡功能，对负载均衡服务，可能会有相当大
的性能问题。
第二种，是目前普遍的做法。可以参考 Zuul 网关，每一个服务都通过服务端内置的功能注册到注册中心，服务消费者不断轮询注册中心发现对应的服务，使用内置负载均衡调用服务。
缺点是，对多语言环境不是很好，你需要单独给消费者的客户端开发服务
发现和负载均衡功能。当然了，这个方法通常都是用在 Spring Cloud
上的。
第三种，是将客户端和负载均衡放在同一个主机，而不是同一个进程内。这种方法相对第一种第二种方法来说，改善了他们的缺点，但是会极大增加运维成本。
网关
微服务的网关是什么？我们可以联系生活实际想一下。每一个大的公司，都会有一偏属于自己的建筑区，而这建筑区内，都有不少的门卫。如果有外来人员进入公司，会先和门卫打好招呼，才能进去。
将生活实际联系到微服务上，就不难理解网关的意思了：
网关的作用如下：
?反向路由：很多时候，公司不想让外部人员看到我们公司的内部，就需要网关来进行反向路由。即将外部请求转换成内部具体服务调用。
?安全认证：网络中会有很多恶意访问，譬如爬虫，譬如黑客攻击，网关维护安全功能。
?限流熔断：当请求很多服务不堪重负，会让我们的服务自动关闭，导致不能用服务。限流熔断可以有效的避免这类问题。
?日志监控：所有的外面的请求都会经过网关，这样我们就可以使用网关来记录日志信息。
?灰度发布，蓝绿部署。是指能够平滑过渡的一种发布方式。在其上可以进行 A/B testing。
即让一部分用户继续用产品特性 A，一部分用户开始用产品特性 B，如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到
B 上面来。
开源网关 Zuul 架构：
Zuul 网关核心其实是一个 Servlet，所有请求都会经过 Zuul
Servlet 传到 ZuulFilter Runner，然后分发到三种过滤器。
先说说架构图左半部分，分别是使用 Groovy 实现的前置路由过滤器，路
由过滤器，后置路由过滤器。
一般请求都会先经过前置路由过滤器处理，一般的自定义 Java 封装
逻辑也会在这里实现。路由过滤器，实现的是找到对应的微服务进行调用。调用完了，响应回来，会经过后置路由过滤器，通过后置路由过滤器我们
可以封装日志审计的处理。
可以说 Zuul 网关最大的特色就是它的三层过滤器。架构图右半部分，是 Zuul 网关设计的自定义过滤器加载机制。网关内部会有生产者消费者
模型，自动的将过滤器脚本发布到 Zuul 网关读取加载运行。
配置中心
以前，开发人员把配置文件放在开发文件里面，这样会有很多隐患。
譬如，配置规范不同，无法追溯配置人员。
一旦需要大规模改动配置，改动时间会很长，无法追溯配置人员，从
而影响整个产品，后果是我们承担不起的。因此就有配置中心这个喽！现
在的开源中心有百度配置中心 Disconf，Spring Cloud Config，Apollo。
今天重点说说现在应用质量不错的配置中心，携程开源的阿波罗（Apollo）：
Apollo 的配置中心规模比较大，本地应用会有响应的配置中心客户端，可以定时同步配置中心里的配置。如果配置中心怠机，会使用缓存来进行配置。
通讯方式
关于通讯方式，一般市面也就是两种远程调用方式，我整理了一个表格：
监控预警
监控预警对于微服务很重要，一个可靠的监控预警体系对微服务运行至关重要。
一般监控分为如下层次：
从基础设施到用户端，层层有监控，全方位，多角度，每一个层面都很重要。
总体来说，微服务可分为 5 个监控点：
?日志监控
?Metrics 监控
?健康检查
?调用链检查
?告警系统
①监控架构
下面的图是大部分公司的一种监控架构图。每一个服务都有一个Agent，Agent 收集到关键信息，会传到一些 MQ 中，为了解耦。同时将日志传入 ELK，将 Metrics 传入 InfluxDB 时间序列库。而像 Nagios，可以定期向 Agent 发起信息检查微服务。
②调用链监控 APM
很多公司都有调用链监控，就譬如阿里有鹰眼监控，点评的 Cat，大部分调用链监控（没错，我指的 Zipkin）架构是这样的：
当请求进入 Web 容器的时候，会经过创建 Tracer，连接 Spans（模拟潜在的分布式工作的延迟，该模块还包含在系统网络间传递跟踪上下文
信息的工具包，如通过 HTTP Headers）。
Spans 有一个上下文，其中包含 Tracer 标识符，将其放在表示分布式操作的树的正确位置。当我们把图中的各种 Span 放到后端的时候，我们的服务调用链会动态的生成调用链。
下面是一些市场上用的比较多的调用链监控对比：
熔断、隔离、限流、降级
面对巨大的突发流量下，大型公司一般会采用一系列的熔断（系统自动将服务关闭防止让出现的问题最大化）、隔离（将服务和服务隔离，防止一个服务挂了其他服务不能访问）、限流（单位时间内之允许一定数量用户访问）、降级（当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用）措施。
下面介绍一下 Hystrix 的运行流程：
每一个微服务调用时，都会使用 Hystrix 的 Command 方式（上图的左上角那个），然后使用 Command 同步的，或者是响应式的，或者是异步的，判断电路是否熔断（顺着图从左往右看），如果断路则走降级Fallback。
如果这个线闭合着，但是线程资源没了，队列满了，则走限流措施（看图的第 5 步）。如果走完了，执行成功了，则走 run() 方法，获取Response，但是这个过程如果出错了，则继续走降级 Fallback。
同时，看图最上面有一个后缀是 Health 的，这是一个计算整个链路是否健康的组件，每一步操作都被它记录着。
容器与服务编排引擎
从物理机到虚拟机，从虚拟机到容器；从物理集群到 OpenStack，OpenStack 到 Kubernetes；科技不断的变化，我们的认知也没刷新。
我们从容器开始说起，它首先是一个相对独立的运行环境，在这一点有点类似于虚拟机，但是不像虚拟机那样彻底。
虚拟机会将虚拟硬件、内核（即操作系统）以及用户空间打包在新虚拟机当中，虚拟机能够利用“虚拟机管理程序”运行在物理设备之上。
虚拟机依赖于 Hypervisor，其通常被安装在“裸金属”系统硬件之上，
这导致 Hypervisor 在某些方面被认为是一种操作系统。一旦
Hypervisor 安装完成，就可以从系统可用计算资源当中分配虚拟机实例了，每台虚拟机都能够获得唯一的操作系统和负载（应用程序）。
简言之，虚拟机先需要虚拟一个物理环境，然后构建一个完整的操作系统，再搭建一层 Runtime，然后供应用程序运行。对于容器环境来说，不需要安装主机操作系统，直接将容器层（比如 LXC 或 Libcontainer）安装在主机操作系统（通常是 Linux 变种）之上。
在安装完容器层之后，就可以从系统可用计算资源当中分配容器实例了，并且企业应用可以被部署在容器当中。但是，每个容器化应用都会共享相同的操作系统(单个主机操作系统)。容器可以看成一个装好了一组特定应用的虚拟机，它直接利用了宿主机的内核，抽象层比虚拟机更少，更加轻量化，启动速度极快。
相比于虚拟机，容器拥有更高的资源使用效率，因为它并不需要为每个应用分配单独的操作系统——实例规模更小、创建和迁移速度也更快。这意味着相比于虚拟机，单个操作系统能够承载更多的容器。云提供商十分热衷于容器技术，因为在相同的硬件设备当中，可以部署数量更多的容器实例。
此外，容器易于迁移，但是只能被迁移到具有兼容操作系统内核的其他服务器当中，这样就会给迁移选择带来限制。因为容器不像虚拟机那样同样对内核或者虚拟硬件进行打包，所以每套容器都拥有自己的隔离化用户空间，从而使得多套容器能够运行在同一主机系统之上。我们可以看到全部操作系统层级的架构都可实现跨容器共享，惟一需要独立构建的就是二进制文件与库。
正因为如此，容器才拥有极为出色的轻量化特性。我们最常用的容器是 Docker。
①容器编排
过去虚拟机可以通过云平台 OpenStack 管理虚拟化，容器时代如何管理容器呢？这就要看看容器编排引擎了。Apache Mesos：Mesos 是基于Master，Slave 架构，框架决定如何利用资源，Master 负责管理机器，Slave 会定期的将机器情况报告给 Master，Master 再将信息给框架。Master 是高可用的，因为 ZK，也有 Leader 的存在。
下面是架构图：
Kubernetes：Kubernetes 是最近十分火热的开源容器编排引擎：
Kubernetes 设计理念和功能其实就是一个类似 Linux 的分层架构，先说说每一个 Kubernetes 节点内部，kubelet 管理全局全局 pod，而每一个 pod 承载着一个或多个容器，kube-proxy 负责网络代理和负载均衡。Kubernetes 节点外部，则是对应的控制管理服务器，负责统一管理各个节点调度分配与运行。
微服务系统设计方案 1.微服务本质 微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。 简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。 对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。 本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。 理解微服务架构和理念是核心。 2.系统环境
3.微服务架构的挑战 可靠性： 由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败， 随着微服务数量的增多，潜在故障点也将增多。 也就是没有充分的保障机制，则单点故障会大量增加。 运维要求高： 系统监控、高可用性、自动化技术 分布式复杂性： 网络延迟、系统容错、分布式事务 部署依赖性强： 服务依赖、多版本问题 性能（服务间通讯成本高）： 无状态性、进程间调用、跨网络调用 数据一致性： 分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务，成本要高得多。另外，在分布式系统中，通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。 重复开发： 微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发，甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了。
微服务架构下的数据一致性
写在前面 随着微服务架构的推广，越来越多的公司采用微服务架构来构建自己的业务平台。就像前边的文章说的，微服务架构为业务开发带来了诸多好处的同时，例如单一职责、独立开发部署、功能复用和系统容错等等，也带来一些问题。 例如上手难度变大，运维变得更复杂，模块之间的依赖关系更复杂，数据一致性难以保证，等等。但是办法总是比问题多，本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的。 微服务架构的数据一致性问题 以电商平台为例，当用户下单并支付后，系统需要修改订单的状态并且增加用户积分。由于系统采用的是微服务架构，分离出了支付服务、订单服务和积分服务，每个服务都有独立数据库做数据存储。当用户支付成功后，无论是修改订单状态失败还是增加积分失败，都会造成数据的不一致。 为了解决例子中的数据一致性问题，一个最直接的办法就是考虑数据的强一致性。那么如何保证数据的强一致性呢？我们从关系型数据库的ACID 理论说起。 ACID 关系型数据库具有解决复杂事务场景的能力，关系型数据库的事务满足ACID 的特性。 ?Atomicity：原子性（要么都做，要么都不做） ?Consistency：一致性（数据库只有一个状态，不存在未确定状态）
?Isolation：隔离性（事务之间互不干扰） ?Durability：永久性（事务一旦提交，数据库记录永久不变） 具有ACID 特性的数据库支持数据的强一致性，保证了数据本身不会出现不一致。 然而微服务架构下，每个微服务都有自己的数据库，导致微服务架构的系统不能简单地满足ACID，我们就需要寻找微服务架构下的数据一致性解决方案。 微服务架构的系统本身是一种分布式系统，而本文讨论的问题其实也就是分布式事务之数据一致性的问题，我们来聊聊分布式系统的CAP 理论和BASE 理论。 CAP CAP 是指在一个分布式系统下，包含三个要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），并且三者不可得兼。 ?C：Consistency，一致性，所有数据变动都是同步的。 ?A：Availability，可用性，即在可以接受的时间范围内正确地响应用户请求。 ?P：Partition tolerance，分区容错性，即某节点或网络分区故障时，系统仍能够提供满足一致性和可用性的服务。 关系型数据库单节点保证了数据强一致性（C）和可用性（A），但是却无法保证分区容错性（P）。 然而在分布式系统下，为了保证模块的分区容错性（P），只能在数据强一致性（C）和可用性（A）之间做平衡。具体表现为在一定时间内，可能模块之间数据是不一致的，但是通过自动或手动补偿后能够达到最终的一致。
微服务框架的设计与实现① 张晶1, 黄小锋2, 李春阳3 1(北京中电普华信息技术有限公司, 北京100192) 2(中国电建集团国际工程有限公司, 北京100048) 3(国网信息通信产业集团有限公司, 北京100031) 摘 要: 相对于传统单块架构, 微服务框架具有技术选型灵活, 独立部署, 按需独立扩展等优点, 更适合当前互联网时代需求. 但微服务架构的使用引入了新的问题, 如服务注册发现、服务容错等. 对微服务框架引入的问题进行分析, 并给出了微服务框架的一种实现方案, 在框架层面解决服务注册发现、服务容错等共性问题, 使业务系统开发人员专注于业务逻辑实现, 简化系统开发的难度, 提高开发效率. 关键词: 微服务框架; 服务注册; 服务发现; 服务容错 Design and Implementation of Microservice Architecture ZHANG Jing1, HUANG Xiao-Feng2, LI Chun-Yang3 1(Beijing China Power Information Technology Co. Ltd., Beijing 100192, China) 2(PowerChina International Group Limited, Beijing 100048, China) 3(State Grid Information & Telecommunication Industry Group Co. Ltd., Beijing 100031, China) Abstract: Compared with traditional single block architecture, microservice architecture has many advantages, such as flexible technology selection, independent deployment, and independent scalability more suitability for the current needs of the internet age, etc. But microservice architecture also introduces new problems such as service registration, service discovery, service fault tolerance. On the basis of the analysis for problems mentioned above, this paper proposes one implementation of microservice framework, which can solve service registration, service discovery, service fault tolerance and other common problems. Based on this, developers only need to focus on the development of business functions, so that it can simplify the difficulty of system development and improve development effectiveness. Key words: microservice architecture; service registration; service discover; fault tolerance 传统信息化系统的典型架构是单块架构(Monolithic Architecture), 即将应用程序的所有功能都打包成一个应用, 每个应用是最小的交付和部署单元, 应用部署后运行在同一进程中. 单块架构应用具有IDE友好、易于测试和部署等优势, 但是, 随着互联网的迅速发展, 单块架构临着越来越多的挑战, 主要表现在维护成本高、持续交付周期长、可伸缩性差等方面[1]. 微服务架构(Microservices)的出现以及在国内外的成功应用, 成为系统架构的一种新选择. 很多大型宝等都已经从传统单块架构迁移到微服务架构[2]. 微服务架构提倡将单块架构的应用划分成一组小的服务, 互联网公司如Twitter、Netflix、Amazon 、eBay、淘服务之间互相协调、互相配合, 为用户提供最终价值. 1 微服务架构 微服务架构是一种架构模式, 采用一组服务的方式来构建一个应用, 服务独立部署在不同的进程中, 不同服务通过一些轻量级交互机制来通信, 例如RPC、HTTP等, 服务可独立扩展伸缩, 每个服务定义了明确的边界, 不同的服务甚至可以采用不同的编程语言来实现, 由独立的团队来维护[3]. 相对于传统的单体应用架构, 微服务架构具有单个服务易于开发、理解和维护; 复杂度可控; 技术选 ①收稿时间:2016-09-18;收到修改稿时间:2016-11-03 [doi: 10.15888/https://www.doczj.com/doc/8b5378344.html,ki.csa.005796]
微服务架构下的服务治理 一、经典微服务架构的特点以及问题 经典的微服务架构一般包含两个部分：API网关，一组微服务。API网关是唯一的请求入口，它还要负责负载均衡，路由编排，失效切换等工作。 经典的微服务架构图
关于经典微服务架构的文章很多，这里重点想分享一些我们实践经典微服务架构的一些问题： 1.“笨重”的API网关，由于它要负责各种核心功能，不能灵活扩展，比如负载均衡策略，也许每 个微服务类型需求都不一样，它很难灵活变更；随着对接的微服务越来越多，每个API网关也集成大量的功能。 2.API网关自身需要高可用保证，经典架构并不提供，随着后端接的微服务越来越多，也会造成很多 稳定性问题，它与微服务也需要两套运维办法，给运维带来额外成本。 3.服务注册与发现还是传统模式，不能级联代理，长连接也有限制，不能很好解决跨大网段，跨机 房，跨IDC中心的问题。
4.心跳机制比较单一，只是从连接层面考虑，没有上下文以及服务本身的监控，需要依赖第三方实 现。 5.失效切换机制单一，只能是联通性检查，对业务异常无感知，意味着不能根据业务异常切换。 6.没有自动高效的重试机制，需要考虑对API网关的改造。 7.几乎没有隔离机制，需要采用第三方技术解决。 8.微服务实现没有统一的技术栈支持，还处于原则规定阶段。 9.服务编排依靠人工，没有动态编排能力。 整体看来，经典微服务架构还不够“聪明和智能”，于是我们设计并着手研发新一代微服务计算平台，希望能够让其充分发挥微服务架构的优势和特性。 二、微服务计算平台的设计思想与抽象模型 1“微智能”的设计思想 “微智能”这个概念起源于智能家居，是目前智能硬件领域的一股创新思想。在提到“智能”这个词，通常是相对人而言，智能家居通过“智”的体现，更好的服务人的生活。于是，我们就思考是否系统或者服务也能体现“智”，如果与微服务相结合，让其更加“聪明”的工作？
基于微服务架构的基础设施设计 摘要：本文首先分析传统的单体架构进而解释微服务架构以及分布式环境下四层架构，详细分析了迁移需解决的关键问题如服务间通信机制、数据最终一致性等；然后分析了分布式系统核心问题和DevOps基本原则，以此为设计依据提出微服务架构基础设施总体设计，并且对其关键组件如服务注册与发现、持续交付平台、服务网关的实施提出具体方案；最后针对微服务架构基础设施在运维管理中的应用场景进行了探讨，说明了微服务架构设计思想优于单体架构设计思想。 关键词：软件工程；微服务；服务注册与发现；持续交付 中图分类号：TP311.5 文献标识码：A DOI： 10.3969/j.issn.1003 6970.2016.05.023 本文著录格式：蒋勇.基于微服务架构的基础设施设计卟软件，2016，37（5）：93-97 0.引言 理论上任何业务系统如果长期存在的话，随着此系统业务变更、功能增加必然会不断演变，在一个更大的分布式环境中，这种改变尤其明显，那么就需要架构分析设计时更多的考虑系统所处的生态环境建设，这样才能使得整个系统不
断进化。随着虚拟化技术的发展以及docker容器实践逐渐完善，微服务架构的设计思想逐渐浮出水面，形成分布式环境下新的最重要的设计思想。文献对分布式环境下资源及应用平台进行了研究，但对于应用自身依赖的基础设施建设没有讨论。本文将详细探讨如何基于微服务架构进行基础设施建设的设计与分析。 1.从分布式单体架构到微服务架构迁移 1.1分布式单体架构 分布式单体架构指的是在分布式环境下直接部署运行 一个整体开发的应用，由整体应用来提供系统所需的服务，它在技术上通常采用分层实现，大致分为表现层、应用层、数据层，它有天然的优势：它是模块独立无关的，各层之间是技术分离的；它有统一的技术栈和开发标准；它通常在一个进程中运行，模块相互之间协同消耗极小。 但是，在分布式环境下，随着系统功能的增加，系统越来越复杂，单体架构存在一些必然的缺陷：首先，由于整个系统是一个完整整体，必须重复部署多个才能提高系统性能，而往往系统瓶颈仅仅由于其中某一个或几个功能过载产生，这就极大浪费了运行环境资源；其次，由于系统功能的变更和演变，某一个功能的变化可能影响其它功能的正常结果，也带来重新部署和运维管理的复杂性，持续集成变得极为困难；最后，由于整个系统采用统一的技术栈和开发标准，必
大规模微服务架构下的Service Mesh探索之路 今天给大家带来的内容叫做Service Mesh探索之路，但是在前面加了一个定语：大规模微服务架构下。之所以加上这个词，是因为我们这个体系是在蚂蚁金服这样一个大的架构下进行的，蚂蚁金服的体量大家可以想象，所以这个探索会带有一个非常隆重的色彩：对性能/规模/高可用等方面的思考。
今年6月初，在深圳的GIAC大会，我们同事披露了这个正在开发中的Service Mesh产品，我们现在暂时命名为Sofa Mesh。我们目前的产品都在Sofa品牌下，比如Sofa RPC，Sofa Boot等。今天我们详细介绍Sofa Mesh这个单独产品，上次大会只是简单披露，也就是给大家介绍说我们有这样一个产品，而我今天的内容是把这个产品详细展开。主要是三个内容：一是Sofa Mesh的技术选型，二是它的架构设计，以及在最后跟大家聊一下，蚂蚁金服在Sofa Mesh上的开源策略。 第一个是技术选型。 先上来一堆要求，刚才我们提到过的，因为是大规模，而蚂蚁金服的体量，大家可以想象到的。实际上在性能，稳定性上，我们的衡量标准，我们考虑的基石，都是以蚂蚁金服这样的一个规模来考虑的。
在这样一个规模下，我们会涉及到一些跟其他公司不太一样的地方，比如说：我们在性能的考量上会比较重一些。因为如果性能不高的话，可能没法支撑我们这样一个规模。在考虑性能的时候，就有另外一层考量：架构和性能之间的这个权衡和取舍是要非常谨慎的。性能要求不太高的情况下，架构可能的选择，和需要比较高性能的情况下，可能会有完全不一样的取舍。稳定性就不必说了。 部署方面的要求，首先是我们会用于多种场合： 主站是指我们蚂蚁金服内部，比如大家用的最多的支付宝。 金融云，可能有一部分和我们有联系的同学会有所了解，这个是我们推出的针对金融行业的云。 然后还有我们的外部客户 部署上会要求这三个场合都能使用。 部署环境也会有多种，刚才我们调查到，有部分同学相对比较前沿一些，现在就已经上k8s了。有部分同学还是停留在以前的虚拟机以及物理机这种状态，也有一部分自己上了容器，还有部分同学可能会使用不同的公有云和私有云。这几种不同的环境，我们都是需要满足的。 第三点可能要特殊一些，需要满足各种体系。刚才我们在调查的时候了解到，有部分同学是在做旧有系统改造，那在改造的时候就会遇到一个问题：除了Service Mesh之外，还需要跟原来的体系，比如说Sofa，或者社区主流框架如Dubbo，Spring Cloud，相互之间打通和过渡。怎么在技术转型期间平滑的让业务做变更，是我们在整个技术选型之前提出的实际要求。整个技术选型是在这样一个背景下进行的。 我们做技术选型的时候，有两大方向： 一个选择是在开源产品上做 我们先看右边的路线，起点是找一个开源产品，fork出来，做增强/扩展/定制，和内部集成。因为开源产品还在继续往前走，所以我们会持续做版本更新，也可以从社区拿到最新版本。相当于是从开源社区做获取，然后接下来做反馈，让我们的一些产品，我们做的东西反馈回去。 这条路线比较大的好处是从一开始就可以得到社区的支持，社区往前走的时候也跟着往前走。如果做的比较好，愿意让自己的产品反哺社区，那么社区也可以从中受益。
微服务架构介绍
微服务是个说的挺长时间的概念，也是比较成熟的技术体系。像Spring Cloud，甚至提供了微服务所需要的全套框架，包括注册中心(Eureka)、配置中心(Config)、断路器(Hytrix)、API 网关(Zuul) 等组件。微服务体系庞杂，每个组件都能独自成章。 微服务与更早就起来的SOA 是什么关系? 个人觉得如果从概念上来说，微服务和SOA 都是一回事，强调把整个系统，按照多个服务的方式去组合及通信，而不是揉合在一起，但它们的内涵有很大的区别。 SOA 诞生在早期企业级的应用，其业务复杂、技术体系多样，SOA 强调的是各个服务之间，尤其是异构系统、遗留系统之间，建立起一套统一的协议和通信(SOAP)，以及寻址服务(UDDI)，它的侧重点在集成和兼容；与SOA 同期的另一种概念ESB(企业总线)，强调通过一根总线服务，把所有服务串联起来，由ESB 总线来屏蔽各种不同业务系统自身业务/ 语言/ 协议的特殊性，各服务以一种统一的方式，与总线相连，从而降低接入成本。 这两种概念，我感觉在国内没有太发展起来。一是国内的软件起步相对较晚，系统的整体复杂度——多厂商、多语言/ 技术栈、历史遗留系统的问题，还不算突出。而对于公司内部的产品系，又没有必要使用SOA、UDDI 来做复杂的集成。随着互联网的兴起和用户量的迅速爆发，企业自身的产品的微服务化的需求，快速发展起来，而与此同时SOA 这种以XML 为基础的SOAP 协议、以寻址为主要作用的UDDI，不能使用互联网产品的发展——SOAP 的XML 协议内容太多，造成性能明显下降；HTTP 协议的效率不如RPC；UDDI 只有寻址，缺少服务治理等功能。 在此种大背景下，以服务切分+ 服务注册+ 服务治理+ 限流降级+RPC+ 监控等为主要内涵的微服务，就快速发展起来的。国内的阿里巴巴走在前列，以Dubbo 为代表在国内互联网企业中得到广泛应用；后来Spring 官方发布Spring Cloud，揉合了一系列自研或其他企业捐赠的开源项目，发布微服务领域的Spring Cloud 产品。各自都有各自的优势和劣势，而
微服务架构技术规范（试行稿） 1总则 目前研发中心的后台开发中，基于Java/Spring MVC/Spring Boot框架开发，每个部门引入的支撑组件却各异，缺乏统一性，甚至每个部门都维护着一堆非业务组件，影响开发人员对快速变化业务支持的专注性。 这套方案的具有较好的可扩展性、可维护性、及良好的代码风格，可以为公司各类型的应用开发提供统一、通用、而强大的基础架构，完全能支持公司所有后台服务沉淀和演化出一个稳健企业中台。 2适用范围 本规范适用于创维数字本部及各分子公司，在使用微服务技术架构进行系统开发时，需遵循此技术规范 3微服务概述 3.1微服务定义 什么是微服务？ 1．微服务- 也称为微服务架构- 是一种架构风格，它将应用程序构建为一组服务 2．高度可维护和可测试 3．松散耦合 4．可独立部署 5．围绕业务能力进行组织。 6．微服务架构支持大型复杂应用程序的持续交付/部署。它还使组织能够
发展其技术堆栈。 Chris Richardson 世界著名软件大师 3.2使用微服务 传统的单体服务，或者模块化不彻底的项目可能存在以下弊端：1．团队职责不清晰 2．构建和部署耗时长 3．全量部署耗时长、影响范围广 4．单体只能按整体横向扩展，无法分模块垂直扩展 5．受技术栈限制，团队成员使用同一框架和语言 6．升级和变革技术框架变得困难 随着软件行业的发展和演变，服务器软件进入了微服务化阶段。对服务的可维护性、可扩展性、可用性这些维度更加让从业人员关注。而微服务化正是解决这些观注的良好的解决方案。所以微服务化正是软件发展演化的结果。在新的目项目应该微服务化解决方案。微服务化的程度可以具体项目具体场景决定。 4开发规范 4.1基本理念 4.1.1无状态服务(Stateless) 无状态就是一次操作，不能保存数据。
微服务架构的部署 本文从以下几个方面简要说明微服务架构项目的实践经验：架构选型、开发测试环境下的相关工具支持、人员分工及开发部署流程、相关设计及注意事项。最后，将根据实践经验讨论提高微服架构下的开发和运维效率的切实需求，进一步理清本项目所实现的容器服务管理平台的完善性需求。 本项目是一个企业级的容器服务管理平台，该平台的功能是基于容器实现的应用运行环境管理，以及应用开发阶段的持续集成和持续发布。简单的理解该平台的核心功能之一就是管理复杂应用的开发和运维环境，提高微服务架构下的开发和运维效率。项目的开发背景如下： 首先，该系统具有典型分布式应用系统特征： 该平台所运行的服务器配置不高，例如华为RH1288这类低配置服务器，允许硬件失败； 系统平台要求可根据实际用户数的规模进行伸缩部署，保证硬件资源的合理利用； 由于系统平台之上需要运行若干企业应用的开发和运行环境，可靠性是非常重要的，不允许单点失效。 其次，本系统功能复杂，从架构的角度需要将系统分成多个层次和若干个子系统。不同的层次、子系统根据具体情况需要采用不同的开发语言，由不同的开发小组完成。 第三，项目组成员由几个城市的异地团队协同开发，统一的开发环境和协同工具是必不可少的。 针对上述项目背景的考虑，本项目选择基于微服务架构进行项目开发。 开发、测试、部署使用到的工具集 “工欲善其事、必先利其器”，借助适合的流程和相关工具集，才能提高微服务架构下的应用开发效率。本项目利用DevOPs流程并选用一套相关工具集实现应用开发管理，提高开发、测试、部署的效率。 代码库：本项目使用分布式代码库Gitlab，它的功能不限于代码仓库，还包括reviews(代码审查), issue tracking(问题跟踪)、wiki等功能，是代码管理和异地团队沟通、协作工具的首选。 Docker镜像仓库、Docker：本项目用容器贯穿整个软件开发流程，以容器作为应用发布的载体，应用的开发环境和测试发版环境都运行在Docker容器中。对于复杂的开发和运维环境管理Docker具有先天的优势，目前国内外的互联网公司有大多数都已经将Docker应用到了他们的开发或者生产环境中了。
微服务架构的部署本文从以下几个方面简要说明微服务架构项目的实践经验：架构选型、开发测试环境下的相关工具支持、人员分工及开发部署流程、相关设计及注意事项。最后，将根据实践经验讨论提高微服架构下的开发和运维效率的切实需求，进一步理清本项目所实现的容器服务管理平台的完善性需求。 本项目是一个企业级的容器服务管理平台，该平台的功能是基于容器实现的应用运行环境管理，以及应用开发阶段的持续集成和持续发布。简单的理解该平台的核心功能之一就是管理复杂应用的开发和运维环境，提高微服务架构下的开发和运维效率。项目的开发背景如下： 首先，该系统具有典型分布式应用系统特征： 该平台所运行的服务器配置不高，例如华为RH1288这类低配置服务器，允许硬件失败； 系统平台要求可根据实际用户数的规模进行伸缩部署，保证硬件资源的合理利用； 由于系统平台之上需要运行若干企业应用的开发和运行环境，可靠性是非常重要的，不允许单点失效。 其次，本系统功能复杂，从架构的角度需要将系统分成多个层次和若干个子系统。不同的层次、子系统根据具体情况需要采用不同的开发语言，由不同的开发小组完成。 第三，项目组成员由几个城市的异地团队协同开发，统一的开发环境和协同工具是必不可少的。 针对上述项目背景的考虑，本项目选择基于微服务架构进行项目开发。 开发、测试、部署使用到的工具集 “工欲善其事、必先利其器”，借助适合的流程和相关工具集，才能提高微服务架构下的应用开发效率。本项目利用DevOPs流程并选用一套相关工具集实现应用开发管理，提高开发、测试、部署的效率。 代码库：本项目使用分布式代码库Gitlab，它的功能不限于代码仓库，还包括reviews(代码审查), issue tracking(问题跟踪)、wiki等功能，是代码管理和异地团队沟通、协作工具的首选。 Docker镜像仓库、Docker：本项目用容器贯穿整个软件开发流程，以容器作为应用发布的载体，应用的开发环境和测试发版环境都运行在Docker容器中。对于复杂的开发和运维环境管理Docker具有先天的优势，目前国内外的互联网公司有大多数都已经将Docker应用到了他们的开发或者生产环境中了。 K8s：本项目采用Kubernates作为容器调度管理的基础环境，开发环境、测试环境的Docker容器都由K8s负责调度管理。 Jenkins：快速的部署发布离不开老牌持续集成明星Jenkins，本项目通过Jenkins任务构建代码、将应用打包成Docker镜像，最终发布到K8s环境中将容器运行起来。 Shell脚本：编写Shell脚本将项目打分支、发布应用等开发阶段的配置管理工作自动化，降低运维门槛、提高配置管理和运维的效率。
微服务架构设计方案
引言：“微服务”是当前软件架构领域非常热门的词汇，能找到很多关于微服务的定义、准则，以及如何从微服务中获益的文章，在企业的实践中去应用“微服务”的资源却很少。本篇文章中，会介绍微服务架构（Microservices Architecture）的基础概念，以及如何在实践中具体应用。 1.单体架构(Monolithic Architecture ) 企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。单体架构的初期效率很高，应用会随着时间推移逐渐变大。在每次的迭代中，开发团队都会面对新功能，然后开发许多新代码，随着时间推移，这个简单的应用会变成了一个巨大的怪物。 图1：单体架构 大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。 多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。
单体架构的应用一般有以下特点： ?设计、开发、部署为一个单独的单元。 ?会变得越来越复杂，最后导致维护、升级、新增功能变得异常困难 ?很难以敏捷研发模式进行开发和发布 ?部分更新，都需要重新部署整个应用 ?水平扩展：必须以应用为单位进行扩展，在资源需求有冲突时扩展变得比较困难（部分服务需要更多的计算资源，部分需要更多内存资源） ?可用性：一个服务的不稳定会导致整个应用出问题 ?创新困难：很难引入新的技术和框架，所有的功能都构建在同质的框架之上 2.微服务架构（Microservices Architecture） 微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。 多数人对于微服务的定义是， 把本来运行在单体架构中的服务拆分成相互独立的服务，并运行在各自的进程中。在我看来，不仅如此。最关键的地方在于，不同的服务能依据不同的业务需求，构建的不同的技术架构之上，并且聚焦在有限的业务功能之上。 因此，在线零售网站可以用图2的微服务架构来简单概括。基于业务需求，需要增加一个账户服务微服务，因此构建微服务绝不是在单体架构中把服务拆分开这么简单。
什么是微服务？就目前而言，对于微服务业界并没有一个统一的、标准的定义。但通常在其而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。 总结了以下几点： ①小服务 小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。 ②进程独立 每一组服务都是独立运行的，可能我这个服务运行在 Tomcat 容器，而 另一个服务运行在 Jetty 上。可以通过进程方式，不断的横向扩展整 个服务。 ③通信 过去的协议都是很重的，就像 ESB，就像 SOAP，轻通信，这意味着相 比过去更智能更轻量的服务相互调用，就所谓 smart endpoints and dumb pipes。
这些 Endpoint 都是解耦的，完成一个业务通信调用串起这些 Micro Service 就像是 Linux 系统中通过管道串起一系列命令业务。 过去的业务，我们通常会考虑各种各样的依赖关系，考虑系统耦合带来 的问题。微服务，可以让开发者更专注于业务的逻辑开发。 ④部署 不止业务要独立，部署也要独立。不过这也意味着，传统的开发流程会 出现一定程度的改变，开发的适合也要有一定的运维职责。 ⑤管理 传统的企业级 SOA 服务往往很大，不易于管理，耦合性高，团队开发 成本比较大。 微服务，可以让团队各思其政的选择技术实现，不同的 Service 可以 根据各自的需要选择不同的技术栈来实现其业务逻辑。 微服务的利与弊 ?优点是每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求。 ?开发简单、开发效率提高，一个服务可能就是专一的只干一件事。 ?微服务能够被小团队单独开发，这个小团队是 2 到 5 人的开发人员组成。?微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。 ?微服务能使用不同的语言开发。 ?易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如 Jenkins，Hudson，bamboo。 ?微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。微服务允许你利用融合最新技术。 ?微服务只是业务逻辑的代码，不会和 HTML，CSS 或其他界面组件混合。?每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。 总的来说，微服务的优势，就是在于，面对大的系统，可以有效的减少复杂程度，使服务架构的逻辑更清晰明了。 但是这样也会带来很多问题，就譬如分布式环境下的数据一致性，测试的复杂性，运维的复杂性。 什么组织适合使用微服务？ 微服务带了种种优点，种种弊端，那么什么组织适合使用微服务？ ①墨菲定律（设计系统）和康威定律（系统划分） 设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。
龙源期刊网 https://www.doczj.com/doc/8b5378344.html, 微服务架构下访问安全性问题的研究 作者：何文强方良柯黄晴晴 来源：《科学导报·学术》2019年第51期 摘 ;要：近年来，微服务的应用开发架构越来越受到软件开发人员的关注和青睐，很多公司都已经开始使用微服务架构来进行应用程序的开发。但是微服务架构的应用，也引入了很多对应的安全问题。本文主要从微服务架构核心安全问题，从用户访问微服务的身份认证和鉴权、微服务与微服务之间的通信时身份认证与鉴权，微服务与第三方通信的边界三个方面进行分析，并对目前针对这些问题常用的解决方案和技术进行研究和探索。 微服务架构的引入为软件的开发带了诸多好处，比如开发语言选择的灵活性，缩短软件的开发周期，减少小团队软件开发成本，增强应用服务的伸缩能力等等。微服务架构在带来各种开发优势的同时，也带了分布式系统的很多安全问题，微服务架构在带来各种开发优势的同时，也带了分布式系统的很多安全问题。对于微服务的安全性问题来说，其应用层的访问权限和鉴权的安全性问题是整个安全体系中占据着至关重要的地位。 1 微服务架构下安全问题简述 微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用服务程序都可以独立在自己的进程中运行，并且相互之间可以使用轻量级机制来进行通信。这些服务程序主要围绕业务进行构建，每个应用程序都可以部署到独立的服务器上，因此其可以使用自动部署机制进行独立部署，而且每个应用服务都可以使用不同的编程语言进行编写，也可以使用不同数据管理技术， 传统的单体应用时，通常所有的服务都是部署在同一台服务器上的，各应用接口之间的调用通常是属于本地调用方式，而且每项服务（或者组件）不需要对用户进行验证。验证工作主要集中由拦截器（如JavaEE的servlet）处理，拦截器对访问身份和全向进行验证审查其是否允许访问。验证完成之后，在不同平台上的不同服务（或者组件）间发送用户登录凭证。而微服务模式下，不同的服务是分别部署在不同的服务器上的，因此每个服务器上都需要进行用户身份验证和鉴权信息。 基于以上现象，微服务架构的身份认证和鉴权问题是影响整个微服务架构安全的核心问题，其对微服务架构的推广和应用起着关键性的作用。 2 微服务架构的身份认证与鉴权问题 2.1用户访问微服务的身份认证和鉴权
微服务架构技术规（试行稿） 1总则 目前研发中心的后台开发中，基于Java/Spring MVC/Spring Boot框架开发，每个部门引入的支撑组件却各异，缺乏统一性，甚至每个部门都维护着一堆非业务组件，影响开发人员对快速变化业务支持的专注性。 这套方案的具有较好的可扩展性、可维护性、及良好的代码风格，可以为公司各类型的应用开发提供统一、通用、而强大的基础架构，完全能支持公司所有后台服务沉淀和演化出一个稳健企业中台。 2适用围 本规适用于创维数字本部及各分子公司，在使用微服务技术架构进行系统开发时，需遵循此技术规 3微服务概述 3.1微服务定义 什么是微服务？ 1．微服务- 也称为微服务架构- 是一种架构风格，它将应用程序构建为一组服务 2．高度可维护和可测试 3．松散耦合 4．可独立部署 5．围绕业务能力进行组织。 6．微服务架构支持大型复杂应用程序的持续交付/部署。它还使组织能够
发展其技术堆栈。 Chris Richardson 世界著名软件大师 3.2使用微服务 传统的单体服务，或者模块化不彻底的项目可能存在以下弊端：1．团队职责不清晰 2．构建和部署耗时长 3．全量部署耗时长、影响围广 4．单体只能按整体横向扩展，无法分模块垂直扩展 5．受技术栈限制，团队成员使用同一框架和语言 6．升级和变革技术框架变得困难 随着软件行业的发展和演变，服务器软件进入了微服务化阶段。对服务的可维护性、可扩展性、可用性这些维度更加让从业人员关注。而微服务化正是解决这些观注的良好的解决方案。所以微服务化正是软件发展演化的结果。在新的目项目应该微服务化解决方案。微服务化的程度可以具体项目具体场景决定。 4开发规 4.1基本理念 4.1.1无状态服务(Stateless) 无状态就是一次操作，不能保存数据。
支付场景的微服务架构介绍
目录 一、SOA与微服务 (3) 二、老支付架构遇到的挑战 (7) 三、基于微服务怎么做的改造 (9) 四、未来规划 (21)
一、SOA与微服务 在我看来，微服务虽是国外传进来的技术，却和咱们中国的一些理论是挂钩的。所以在正式进入主题之前，先给大家简单介绍一下麦田理论。 1.关于麦田理论 古代周朝时期，老百姓种地实际是没有任何规划的，也没有任何区域的限制，一般来说在地里一会种水稻，一会种小麦，一会种蔬菜地交叉来种，可收成之后发现庄稼受阳光程度非常低，营养非常不均
衡，后期维护成本非常高。直到战国时期，有一位农业专家把地划分为多个区域，每一个区域种一种庄稼，地跟地隔开，形成最初的微服务理念。 过去我们看到的很多文章都只是讲到SOA和微服务之间的比较，我今天在这个基础上加了一个DDD。下面就DDD、SOA以及微服务的演进过程先做个引子。 2.DDD、SOA与微服务
SOA架构 SOA是上一个时代的产物，大概是在2010年之前出现的，最早提出时是提供给传统行业计算领域的解决方案，当时Oracle、IBM也提了很多方案，包括出现的很多流程引擎。
它的思想是将紧耦合的系统，划分为面向业务的粗粒度、松耦合、无状态的服务。在这之后，微服务的提出者基于SOA做了一个改进，就把它变成单一职责、独立部署、细小的微服务，是一个相反的概念。 微服务与DDD 今天我们一说到微服务就会想到DDD，有不少朋友认为DDD就是为微服务而生的。其实不是这样的，我在接触DDD时它最早是用来做UML设计、领域建模的。 DDD讲究充血模型，而J2EE模型以传统的分层架构和Spring架构捆绑在一起形成了以贫血模型为主的架构模式，贫血模型的优点是容易入门、分层清晰，而充血模型要求设计者前期对业务理解较深，不然后期项目会产生混乱。 另外就是DDD思想比较宽泛，导致形成百家争鸣的姿态，没有形成一套固定的方法论。开发者不容易理解，所以后面关注DDD的人变少了，而微服务的提出巧妙地借鉴了DDD里面的限界上下文、子域、领域事件等关键词，在微服务得到越来越多业界认可的情况下，也给DDD带来了重新的焕发。
微服务架构的核心要点和实现原理
目录 一、微服务架构中职能团队的划分 (3) 二、微服务的去中心化治理 (5) 三、微服务的交互模式 (6) 四、微服务的分解和组合模式 (11) 五、微服务的容错模式 (32) 六、微服务的粒度 (43)
一、微服务架构中职能团队的划分 传统单体架构将系统分成具有不同职责的层次，对应的项目管理也倾向于将大的团队分成不同的职能团队，主要包括：用户交互UI团队、后台业务逻辑处理团队与数据存取ORM团队、DBA团队等。每个团队只对自己分层的职责负责，并对使用方提供组件服务质量保证。如果其中一个模块化组件需要升级、更新，那么这个变更会涉及不同的分层团队，即使升级和变更的改变很小，也需要进行跨团队沟通：需求阶段需要跨团队沟通产品功能，设计阶段需要跨团队沟通设计方案，开发阶段需要跨团队沟通具体的接口定义，测试阶段需要沟通业务回归等事宜，甚至上线都需要跨团队沟通应用的上线顺序。可见在传统的整体架构下，后期的维护成本很高，出现事故的风险很大。 根据康威定律，团队的交流机制应该与架构设计机制相对应。因此，在微服务架构下，职能团队的划分方法是我们首先要考虑的一个核心要素。 微服务时代的团队沟通方式如图1-9所示。
图1-9 微服务架构按照业务的功能进行划分，每个单一的业务功能叫作一个服务，每个服务对应一个独立的职能团队，团队里包含用户交互UI设计师、后台服务开发人员、DBA、运营和运维人员。
在传统的整体架构中，软件是有生命周期的，经历需求分析、开发和测试，然后被交付给运维团队，这时开发团队将会解散，这是对软件的一个“放手”。而在微服务架构中，提倡运维人员也是服务项目团队的一员，倡导谁开发、谁维护，实施终生维护制度。 在业务服务的内部实现需要升级或者变更时，团队内的各角色成员进行沟通即可，而不需要进行跨团队沟通，这大大提高了沟通效率。只有服务之间的接口需要变更时才需要跨部门沟通，如果前期在服务之间的交互上定义了良好的接口，则接口变更的概率并不大，即使接口模式有变更，也可以通过一定的设计模式和规范来解决，可参考1.3.3节。 二、微服务的去中心化治理 笔者曾经在一个互联网平台上工作，平台的决策者倡导建设API网关，所有外部服务和内部服务都由统一的API网关进行管理。在项目初期，中心化的API网关统一了所有API的入口，这看起来很规范，但从技术角度来看限制了API的多样化。随着业务的发展，API网关开始暴露问题，每个用户请求经过机房时只要有服务之间的交互，则都会从API网关进行路由，服务上量以后，由于内部服务之间的交互都会叠加在API网关的调用上，所以在很大程度上放大了API网关的调用TPS，API网关很快就遇到了性能瓶颈。 这个案例是典型的微服务的反模式，微服务倡导去中心化的治理，不推荐每个微服务都使用相同的标准和技术来开发和使用服务。在微服务架构下可以使用C++开发一个服务，来对接Java 开发的另外一个服务，对于异构系统之间的交互标准，通常可以使用工具来补偿。开发者可以开发共用的工具，并分享给异构系统的开发者使用，来解决异构系统不一致的问题，例如：Thrift 远程调用框架使用中间语言（IDL）来定义接口，中间语言是独立于任何语言的，并提供了工具来生成中间语言，以及在中间语言与具体语言之间的代码转换。
2019年第6期信息通信2019 (总第198期)INFORMATION&COMMUNICATIONS(Sum.No198) 基于微服务体系的服务框架的设计 周素青 (福建信息职业技术学院，福建福州350003) 摘要:与传统的单体架构相比，微服务架构有着基于独立服务、按需收缩、易于开发和维护等优点。文章针对传统单体架构和微服务架构的优劣对比的基础上，提出了如何从零开始构建微服务以及如何将现有的单体应用改遥成微服务的实施方案,通过该方案实现快速有效的模型迁移O 关键词:伸缩立方体;微服务;API Gateway;服务发现 中图分类号：TP39文献标识码:A文章编号：1673?1131(2019)06-0069-04 Title IWIWIWIWIWIWIWIWIWTmeTmeTmeTme Zhou Suqing (Fujian Polytechnic oflnfimnation Technology,fuzhou350003,China) Abstract:Compared with traditional monolithic architecture,micro-service architecture has many advantages,such as indepen-dent service,shrinkage on demand,easy development and maintenance.Based on the comparison of t he advantages and disad-vantages of t raditional monolithic architecture and micro-service architecture,this paper proposes how to build micro-services from scratch and how to transform existing monolithic applications into micro-sravices,through which to achieve rapid and ef-fective model migration. Key words:Scale Cube;micro-service^PI Gateway;Service discovery 1微服务的介绍 1.1微服务的定义 微服务(Microservices)概念的版本很多,这里选取维基百科上的定义作为本文的标准:微服务是一种软体架构风格，它 是以专注于单一责任与功能的小型功能区块为基础，利用模 组化的方式组合出复杂的大型应用程式，各功能区块使用与语言无关的API集相互通讯叫 1.2Scale Cube 说到微服务不能不提到Martin L.Abbott所提出的的三维 图］伸缩立方体(ScaleCube) X轴伸缩是指通过部署多个相同的应用来实现事务的快速扩展。以餐厅厨房为例说明X轴扩展：厨师为了做出一道美食,需要经历选择食材、处理食材、调配酱料、烹饪食材、成品装盘五个步骤。餐厅为了更高效的服务顾客，请来了多名厨师来的完成这些过程，厨师之间制作美食的过程是相互独立的。显而易见，虽然餐厅服务顾客的效率变高了，但是餐厅的成本也大大提高了，同时厨师完成这些过程的复杂度并没有改变，而且为了让厨师提供无差别服务，就需要在厨师之间 “同步数据”，这就需要保持数据的一致性。所以X轴伸缩的不足在于每份都克隆需要访问所有数据，这就需要更多内存实现缓存，运维的成本过高叫 Z轴伸缩，也称为分片，指根据用户的属性对服务进行拆 分。它与X轴伸缩有些许类似,不同之处在于Z轴伸缩只对应用和数据进行分片，每个应用负责对应属性的数据子集。还 是餐厅厨师的例子，厨师制作美味还是需要上面五个步骤，但 是不需要每个厨师都要会做川菜、粤菜、湘菜,根据客户喜好 合理的分配不同菜系的厨师的数量。Z轴伸缩常用在大型数据类集或者差别服务，它不仅提高了缓存的利用率,还提升了 事务的可伸缩性，实现了不同客户群体的故障隔离。这样在 一定程度上提升了餐厅的效率并且减少了餐厅的成本，但是 还是没有减少单个厨师的工作复杂程度，并且对于顾客点单 到分配到具体厨师的过程也提高了复杂度，所以Z轴伸缩不仅没能降低开发和应用复杂度，反而在路由策略上还提高了系统的复杂度，并且涉及到数据重新分区的时候，又将会是一个令人头疼的事情。 与X轴和Z轴的“复制”的做法不同,Y轴伸缩按功能将应用分解成一组具有一定松散耦合度的协作服务，每个服务 实现单个或多个相关的功能。Y轴伸缩基于不同的业务来分解工作职责。比如餐厅老板意识到降低厨师的工作流程的复 杂度才是提高效率、降低成本最有效的手段，于是请来配菜师 傅员责选择食材、调配酱料，砧板师傅员责处理食材，这样厨师就只需要烹饪食材和成品装盘两个步骤了。这样就降低了厨师的工作复杂度,同时对于餐厅也可以减少一定量的厨师,增加的只是薪资远低于厨师的配菜师傅和砧板师傅，餐厅的成本也就降低了，大家都能更专业更有效的完成自己的工作。 三个维度特点各不相同，各自独立,但每个维度都可以按 各自的需要扩展。X轴扩展能够解决系统的事务员载压力,但是如果系统的复杂度或面对的吞吐量不断增加，或者需要差 异化服务时,X轴扩展就无法满足需求了。此时可以分别通过 69