使用visio手绘的 Spring Cloud 微服务框架，包含路由、服务注册、服务交互、配置管理

(附带安装和说明)sentinel是面向分布式服务框架的轻量级流量控制框架,主要以流量为切入点,从流量控制,熔断降级,系统负载保护等多个维度来维护系统的稳定性。

微服务架构的诞生和容器技术的流行，几乎是同时发生的，这并非偶然，而是互联网时代倒逼传统技术和架构而产生的变革，而以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制，本文作者从什么是微服务切入，详细的介绍了微服务架构的优势，最后从自身实践出发，给出了微服务架构的云端实践。近年来，微服务架构及容器技术备受关注，在各类文章、演讲、博客中频频亮相，成为业界最热门的话题。在时尚的词汇和热情满满的讨论背后，人们开始严肃的重新思考互联网时代服务的架构以及应用开发、运维的方法。微服务以一种全新的架构设计模式，牵动了互联网应用从设计到运维整个流程方法论的变革。??而以Docker为代表的容器技术则

今天开始聊一些微服务的实践，第一块，RPC框架的原理及实践，为什么说要搞定微服务架构，先搞定RPC框架呢?服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦，如下图：服务A是欧洲团队提供服务，欧洲团队的技术背景是Java，可以用Java实现服务;服务B是美洲团队提供服务，可以用C++实现服务;服务C是中国团队提供服务，可以用Go实现服务;服务的上游调用方，按照接口、协议即可完成对远端服务的调用。但实际上，99.9%的公司的团队规模有限，技术团队人数也有限，基本是使用同一套技术体系来调用和提供服务的：这样的话，如果没有统一的服务框架，RPC框架，各个团队的服

微服务架构解决了很多问题，但是同时引入了很多问题。本文要探讨的是如何解决下面这几个问题。依赖的微服务调用失败了，我应该失败，还是成功。依赖很多外部服务之后，自身如何保障稳定性。如果所有依赖的服务成功，我才算成功，自身的稳定性就堪忧了。如果调用失败时，选择跳过。那么因此产生的数据不一致性问题如何修复？平时毛毛雨，可以忽略。但是大故障之后，人工还是要来擦屁股的，这个成本就特别高。使用消息队列的最大的意义是在让消息可以在故障的时候堆积起来，等故障恢复了再慢慢来处理，减少人工介入的成本。依赖消息队列做系统解耦的时候，怎么确保消息自身是可靠入队列的？消息是否需要先可靠写入队列，然后再提交数据库事务？如果

上图是互联网典型的高可用架构，大部分公司如果没有使用微服务，正在使用这样的架构：1.用户端是浏览器browser，APP客户端2.后端入口是高可用的nginx集群，用于做反向代理3.中间核心是高可用的web-server集群，研发工程师主要在这一层进行编码工作4.后端存储是高可用的db集群，数据存储在这一层。更典型的公司，web-server层是通过DAO/ORM等技术来访问数据库。最初的架构都没有服务层，这样的架构会遇到怎样的痛点？对于没有使用微服务架构的公司来说，要不要升级到微服务架构呢？回答这个问题之前，先来看看您是否遇到和58同城及58到家类似的架构痛点：。A、B、C业务线，如果没有微

我一直在用draw.io做一些和UML流程图，图表或者曲线图相关的事情。它在丰富的功能和用户的手工控制方面做出了合理的权衡。但是，接下来我会告诉你如何自动化一些无聊的鼠标点击;）DanielWoods的“Microservices:TheRightWay”演讲里其中一张幻灯片如果它不是这样的话事情也不会变得这么有趣。事实上，这里最好能有一张更清晰地展现组件之间关系和职责的图片。不然的话最终结果就是像上面看到的这样;)诀窍便是在做的时候不断审视它哪个地方不对，这样一来便不太可能做的这么糟了。在做图的时候——你也在同时给自己一个整体的感觉，它们将会怎么交互，问题域是什么，上下文，边界，等等。"光纸

简单来说，服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB），并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈，而SpringCloud就是其中的佼佼者。DevOps是英文Development和Operations的合体，他要求开发、测试、运维进行一体化的合作，进行更小、更频繁、更自动化的应用发布，以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚，也方便运维和管理。这个理念与微服务理念不谋而合。接下来我们从服务化架构演进的角度来看看为什么Spring

软件工程发展大师级人物MartinFowler在他谈论微服务的个人主页上提到，微服务并没有一个非常明确的定义。事实上有很多种分布式系统的实现都可以被看成（或者说勉强看成）是面向微服务架构的。微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTfulAPI）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言

之前一段时间，有听部门架构说起接下来公司要使用微服务架构来研发系统，当时没怎么在意，因为是第一次听说微服务这个名词（果然无知者无畏啊）；正好赶上五一假，我自告奋勇的，接了编写微服务架构培训文档这个任务（也许因为我是文科生，文笔稍微好点）。五一假期三天，基本都是在看资料，梳理思路以及编写接下来的培训文档中度过。下面，就说说我这几天的一些收获吧；先说说资料来源吧：有架构给我的一些资料，以及自己百度和论坛、社区找来的一些资料，权当做一个总结式的简介。。。微服务架构（MicroserviceArchitecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其