微服务架构设计纲要

微服务

软件架构是一个包含各类组织的系统组织，这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通信层), 它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。

Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.

（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。)

Monolithic架构

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

开发简单直接，集中式管理, 基本不会重复开发

功能都在本地，没有分布式的管理开销和调用开销。它的缺点也很是明显，特别对于互联网公司来讲（不一一列举了）：

开发效率低：全部的开发在一个项目改代码，递交代码相互等待，代码冲突不断

代码维护难：代码功能耦合在一块儿，新人不知道何从下手

部署不灵活：构建时间长，任何小修改必须从新构建整个项目，这个过程每每很长

稳定性不高：一个微不足道的小问题，能够致使整个应用挂掉

扩展性不够：没法知足高并发状况下的业务需求

微服务架构

微服务是指开发一个单个小型的但有业务功能的服务，每一个服务都有本身的处理和轻量通信机制，能够部署在单个或多个服务器上。微服务也指一种种松耦合的、有必定的有界上下文的面向服务架构。也就是说，若是每一个服务都要同时修改，那么它们就不是微服务，由于它们紧耦合在一块儿；若是你须要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。

相对于单体架构和SOA，它的主要特色是组件化、松耦合、自治、去中心化，体如今如下几个方面：

• 一组小的服务

服务粒度要小，而每一个服务是针对一个单一职责的业务能力的封装，专一作好一件事情。

• 独立部署运行和扩展

每一个服务可以独立被部署并运行在一个进程内。这种运行和部署方式可以赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。

• 独立开发和演化

技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术能够独立演化。服务与服务之间采起与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。

• 独立团队和自治

团队对服务的整个生命周期负责，工做在独立的上下文中，本身决策本身治理，而不须要统一的指挥中心。团队和团队之间经过松散的社区部落进行衔接。

咱们能够看到整个微服务的思想就如咱们如今面对信息爆炸、知识爆炸是同样的：经过解耦咱们所作的事情，分而治之以减小没必要要的损耗，使得整个复杂的系统和组织可以快速的应对变化。

咱们为何采用微服务呢？

"让咱们的系统尽量快地响应变化" - Rebecca Parson

让咱们的系统尽量快地去响应变化。其实几十年来咱们一直在尝试解决这个问题。若是必定要在前面加个限制的话，那就是低成本的快速响应变化。上世纪90年代Kent Beck提出要拥抱变化，在同期出现了诸多轻量级开发方法（诸如 XP、Scrum）；2001年敏捷宣言诞生，以后又出现了精益、看板等新的管理方式。若是说，这些是为了尽快的响应变化，在软件开发流程和实践方面提出的解决方案，那么微服务架构就是在软件技术和架构层面提出的应对之道。

Autonomous
A Microservice is a unit of functionality; it provides an API for a set of capabilities oriented around a business domain or common utility

Isolated
A Microservice is a unit of deployment; it can be modified, tested and deployed as a unit without impacting other areas of a solution

Elastic
A Microservice is stateless; it can be horizontally scaled up and down as needed

Resilient
A Microservice is designed for failure; it is fault tolerant and highly available

Responsive
A Microservice responds to requests in a reasonable amount of time

Intelligent
The intelligence in a system is found in the Microservice endpoints not ‘on the wire’

Message Oriented
Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

Programmable
Microservices provide API’s for access by developers and administrators

Composable
Applications are composed from multiple Microservices

Automated
The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution

服务之间如何通讯

通常同步调用比较简单，一致性强，可是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个颇有意 思的话题。通常REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要 求，只要封装了HTTP的SDK就能调用，因此相对使用的广一些。RPC也有本身的优势，传输协议更高效，安全更可控，特别在一个公司内部，若是有统一个 的开发规范和统一的服务框架时，他的开发效率优点更明显些。就看各自的技术积累实际条件，本身的选择了。而异步消息的方式在分布式系统中有特别普遍的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能 保证调用方的服务体验，继续干本身该干的活，不至于被后台性能拖慢。不过须要付出的代价是一致性的减弱，须要接受数据最终一致性；还有就是后台服务通常要 实现幂等性，由于消息发送出于性能的考虑通常会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

微服务优势

• 每一个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
• 微服务可以被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，不管是在开发阶段或部署阶段都是独立的。
• 微服务能使用不一样的语言开发。
• 微服务容许容易且灵活的方式集成自动部署，经过持续集成工具，如Jenkins, bamboo 。
• 一个团队的新成员可以更快投入生产。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队可以更关注本身的工做成果。无需经过合做才能体现价值。
• 微服务容许你利用融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其余界面组件混合。
• 微服务可以即时被要求扩展。
• 微服务能部署中低端配置的服务器上。
• 易于和第三方集成。
• 每一个微服务都有本身的存储能力，能够有本身的数据库。也能够有统一数据库。

微服务架构的缺点

• 微服务架构可能带来过多的操做。
• 须要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
• 可能双倍的努力。
• 分布式系统可能复杂难以管理。
• 由于分布部署跟踪问题难。
• 当服务数量增长，管理复杂性增长。

须要考虑的问题

• 单个微服务代码量小，易修改和维护。可是，系统复杂度的总量是不变的，每一个服务代码少了，但服务的个数确定就多了。就跟拼图游戏同样，切的越碎，越难拼出整幅图。一个系统被拆分红零碎的微服务，最后要集成为一个完整的系统，其复杂度确定比大块的功能集成要高不少。
• 单个微服务数据独立，可独立部署和运行。虽然微服务自己是能够独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通讯，当微服务的数量达到必定量级的时候，如何提供一个高效的集群通讯机制成为一个问题。
• 单个微服务拥有本身的进程，进程自己就能够动态的启停，为无缝升级的打好了基础，但谁来启动和中止进程，什么时机，选择在哪台设备上作这件事情才是无缝升级的关键。这个能力并非微服务自己提供的，而是须要背后强大的版本管理和部署能力。
• 多个相同的微服务能够作负载均衡，提升性能和可靠性。正是由于相同微服务能够有多个不一样实例，让服务按需动态伸缩成为可能，在高峰期能够启动更多的相同的微服务实例为更多用户服务，以此提升响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其余相同的微服务能够接替其工做，对外表现为某个设备故障后业务不中断。一样的道理，微服务自己是不会去关心系统负载的，那么何时应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起做用。
• 微服务能够独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就须要有一个统一的入口，新的服务能够动态的注册到这个入口上，用户每次访问时能够从这个入口拿到系统全部服务的访问地址。这个统一的系统入口并非微服务自己的一部分，因此这种能力须要系统单独提供。
• 还有一些企业级关注的系统问题，好比，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而须要有一个系统性的考虑和设计，让每一个微服务都可以按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。

API为何很重要

• 服务价值的精华体现
• 可靠、可用、可读
• 只有一次机会

实现一个API网关做为全部客户端的惟一入口。API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上，其余的请求被转给到一组服务。

相比于提供普适的API，API网关根据不一样的客户端开放不一样的API。好比，Netflix API网关运行着客户端特定的适配器代码，会向客户端提供最适合其需求的API。

API网关也能够实现安全性，好比验证客户端是否被受权进行某请求。

设计要素

• Version
• RequstID
• Auth&Signature
• RateLimit
• Docs
• ErrorCode&Message

微服务治理

• 按需伸缩

–部署与监控运维成本

• 独立部署

–机器数量与部署成本

• 业务独立

–服务依赖、治理，版本管理、事务处理

• 技术多样性

–环境部署成本、约定成本

• 运行状态治理

–监控、限流、SLA、LB、日志分析

• 服务注册与发现
• 部署

–快速、复制、扩容
–单机开发

• 调用

–安全、容错、服务降级、调用延时

服务容错

当企业微服务化之后，服务之间会有错综复杂的依赖关系，例如，一个前端请求通常会依赖于多个后端服务，技术上称为1 -> N扇出. 在实际生产环境中，服务每每不是百分百可靠，服务可能会出错或者产生延迟，若是一个应用不能对其依赖的故障进行容错和隔离，那么该应用自己就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内致使全部应用资源(线程，队列等)被耗尽，形成所谓的雪崩效应(Cascading Failure)，严重时可致整个网站瘫痪。

服务依赖

服务框架

1. 服务注册、发现、负载均衡和健康检查，假定采用进程内LB方案，那么服务自注册通常统一作在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。
2. 监控日志，框架一方面要记录重要的框架层日志、metrics和调用链数据，还要将日志、metrics等接口暴露出来，让业务层能根据须要记录业务日志数据。在运行环境中，全部日志数据通常集中落地到企业后台日志系统，作进一步分析和处理。
3. REST/RPC和序列化，框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来，HTTP/REST是当前主流API暴露方式，在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出Ajax友好的JSON消息格式，而对无线设备上的Native App，框架支持输出性能高的Binary消息格式。
4. 配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，可以在运行时针对不一样环境动态调整服务的参数和配置。
5. 限流和容错，框架集成限流容错组件，可以在运行时自动限流和容错，保护服务，若是进一步和动态配置相结合，还能够实现动态限流和熔断。
6. 管理接口，框架集成管理接口，一方面能够在线查看框架和服务内部状态，同时还能够动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
7. 统一错误处理，对于框架层和服务的内部异常，若是框架层可以统一处理并记录日志，对服务监控和快速问题定位有很大帮助。
8. 安全，安全和访问控制逻辑能够在框架层统一进行封装，可作成插件形式，具体业务服务根据须要加载相关安全插件。
9. 文档自动生成，文档的书写和同步一直是一个痛点，框架层若是能支持文档的自动生成和同步，会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。
10. 想要了解更多微服务架构知识点的，能够关注我一下，我后续也会整理更多这一块的知识点分享出来，另外顺便在这里给你们推荐一个Java后端的交流社区：586446657，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。相信对于已经工做和遇到技术瓶颈的码友，在这里必定有你须要的内容。

微服务系统底座

一个完整的微服务系统，它的底座最少要包含如下功能：

• 日志和审计，主要是日志的汇总，分类和查询
• 监控和告警，主要是监控每一个服务的状态，必要时产生告警
• 消息总线，轻量级的MQ或HTTP
• 注册发现
• 负载均衡
• 部署和升级
• 事件调度机制
• 资源管理，如：底层的虚拟机，物理机和网络管理

如下功能不是最小集的一部分，但也属于底座功能：

• 认证和鉴权
• 微服务统一代码框架，支持多种编程语言
• 统一服务构建和打包
• 统一服务测试
• 微服务CI/CD流水线
• 服务依赖关系管理
• 统一问题跟踪调试框架，俗称调用链
• 灰度发布
• 蓝绿部署

容器（Docker）与微服务

• 容器够小

–解决微服务对机器数量的诉求

• 容器独立

–解决多语言问题

• 开发环境与生产环境相同

–单机开发、提高效率

• 容器效率高

–省钱

• 代码/image一体化

–可复用管理系统

• 容器的横向与纵向扩容

–可复制
–可动态调节CPU与内存

容器(Docker)与微服务

• Image管理
• 系统安全管理
• 受权管理
• 系统成熟度
• 社区成熟度

开发方式影响

随着持续交付概念推广以及Docker容器普及，微服务将这两种理念和技术结合起来，造成新的微服务+API + 平台的开发模式，提出了容器化微服务的持续交付概念。
下图传统Monolithic的DevOps开发队伍方式：

这种总体型架构要求产品队伍横跨产品管理 Dev开发 QA DBA 以及系统运营管理，而微服务架构引入之后，以下图：

微服务促进了DevOps方式的重组，将一个大臃肿的总体产品开发队伍切分为根据不一样微服务的划分的产品队伍，以及一个大的总体的平台队伍负责运营管理，二者之间经过API交互，作到了松耦合隔绝。

• 首先须要考虑构建DevOps能力，这是保证微服务架构在持续交付和应对复杂运维问题的动力之源；
• 其次保持服务持续演进，使之可以快速、低成本地被拆分和合并，以快速响应业务的变化；
• 同时要保持团队和架构对齐。微服务貌似是技术层面的变革，但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另外一大支柱。
• 最后，打造持续改进的自组织文化是实施微服务的关键基石。只有持续改进，持续学习和反馈，持续打造这样一个文化氛围和团队，微服务架构才能持续发展下去，保持新鲜的生命力，从而实现咱们的初衷。

微服务的实施是有必定的先决条件：基础的运维能力（如监控、快速配置、快速部署）需提早构建，不然就会陷入如咱们般被动的局面。推荐采用基础设施及代码的实践，经过代码来描述计算和网络基础设施的方法，使得图案度i能够快速安全的搭建和处理由新的配置代替的服务器，服务器之间能够拥有更高的一致性，下降了在“个人环境工做，而你的环境不工做”的可能，也是为后续的发布策略和运维提供更好的支撑。

因为Docker引入，不一样的微服务可使用不一样的技术架构，好比Node.js Java Ruby Python等等，这些单个的服务均可以独立完成交付生命周期，以下：

微服务案例

Netflix的微服务架构以下，着重全球分发 高可扩展性和可用性：

Twitter的微服务架构，注重高效的可扩展的数据中心：

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

但愿对您系统架构，软件项目开发,运维管理，系统架构与研发管理体系, 信息安全, 企业信息化等有帮助。

文章转载自博客园：PetterLiu

原文连接：www.cnblogs.com/wintersun/p…