微服务的安全
OAuth 是一个关于授权的开放网络标准，它允许第三方网站在用户授权的前提下访问用户在服务商那里存储的各种信息。实际上，OAuth 2.0 允许用户提供一个令牌给第三方网站，一个令牌对应一个特定的第三方网站，同时该令牌只能在特定的时间内访问特定的资源。用户在客户端使用用户名和密码在用户中心获得授权，然后客户端在访问应用是附上 Token 令牌。此时，应用接收到客户端的 Token 令牌到用户中心进行认证。
一般情况下，access token 会添加到 HTTP Header 的 Authorization 参数中使用，其中经常使用到的是 Bearer Token 与 Mac Token。其中，Bearer Token 适用于安全的网络下 API 授权。MAC Token 适用于不安全的网络下 API 授权。
对于快速追踪与定位问题
在微服务复杂的链式调用中，我们会比单体架构更难以追踪与定位问题。因此，在设计的时候，需要特别注意。一种比较好的方案是，当 RESTful API 接口出现非 2xx 的 HTTP 错误码响应时，采用全局的异常结构响应信息。其中，code 字段用来表示某类错误的错误码，在微服务中应该加上“{biz_name}/”前缀以便于定位错误发生在哪个业务系统上。我们来看一个案例，假设“用户中心”某个接口没有权限获取资源而出现错误，我们的业务系统可以响应“UC/AUTH_DENIED”，并且通过自动生成的 UUID 值的 request_id 字段，在日志系统中获得错误的详细信息。
HTTP/1.1 400 Bad RequestContent-Type: application/json{ "code": "INVALID_ARGUMENT", "message": "{error message}", "cause": " ...
微服务如何进行数据库管理
分布式数据管理之痛点为了确保微服务之间松耦合，每个服务都有自己的数据库, 有的是关系型数据库(SQL)，有的是非关系型数据库(NoSQL)。开发企业事务往往牵涉到多个服务，要想做到多个服务数据的一致性并非易事，同样，在多个服务之间进行数据查询也充满挑战。我们以一个在线 B2B 商店为例，客户服务包括了客户的各种信息，例如可用信用等。管理订单，提供订单服务，则需要验证某个新订单与客户的信用限制没有冲突。在单体应用中，订单服务只需要使用传统事务交易就可以一次性检查可用信用和创建订单。相反微服务架构下，订单和客户表分别是相应服务的私有表，如下图所示：
订单服务不能直接访问客户表，只能通过客户服务发布的 API 来访问或者使用分布式事务, 也就是众所周知的两阶段提交 (2PC)来访问客户表，2PC 意义图如下所示：
这里存在两个挑战：
第一个挑战是 2PC 除要求数据库本身支持外，还要求服务的数据库类型需要保持一致。但是现在的微服务架构中，每个服务的数据库类型可能是不一样的，有的可能是 MySQL 数据库，有的也可能是 NoSQL 数据库;
第二个挑战是如何实现从多个服务中查询数据。假设 ...
如何应对微服务的链式调用异常
一般情况下，每个微服务之间是独立的，如果某个服务宕机，只会影响到当前服务，而不会对整个业务系统产生影响。但是，服务端可能会在多个微服务之间产生一条链式调用，并把整合后的信息返回给客户端。在调用过程中，如果某个服务宕机或者网络不稳定可能造成整个请求失败。因此，为了应对微服务的链式调用异常，我们需要在设计微服务调用链时不宜过长，以免客户端长时间等待，以及中间环节出现错误造成整个请求失败。此外，可以考虑使用消息队列进行业务解耦，并且使用缓存避免微服务的链式调用从而提高该接口的可用性。
如何拆分服务
如今，市场环境纷繁复杂，瞬息万变，现代企业为了更好地生存，需要有极强的适应能力。快速而轻松地迎接改变，成为了一个优质企业的特征之一，同时企业还要求技术团队构建更科学的架构，搭建成本更低的平台，这就使得这些团队越来越倾向于使用微服务架构来应对以上要求。
微服务的做法有利于软件组件和数据的分散化，将一个整体分解成更小、更容易改变的部分，分散仅帮助团队加快工程进度，而不会牺牲系统的安全性。要想让这种架构工作得很好，需要改变工作方式。
微服务架构的设计，其实是为了使团队能够在执行工作的人之间分配决策权力，向更多成员直接推行决策权，允许他们以更自由的方式生产。微服务架构使用正确的话，将产生更好和更快的变化。但是如果你的架构错误，那么一系列坏的决定可能会降低转化率，甚至会损害你的业务。
我们讲决策权分配，即是说微服务架构的拆分实际上就是在寻求正确的权力下放战略。这是一个进化过程，需要不断地进行分析和调整。而如何正确的拆分微服务架构，我认为可以重点从以下三个方面考虑：
1. 我们应该做哪些决定？设计微服务系统不仅仅是改变组件大小，架构中涉及创建和更改服务的所有领域都有一定的作用。在这里总结了以下九 ...
微服务与 SOA 的区别
微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。
较早实践微服务的公司 Netflix 就曾经称他们构建的架构是「细粒度的 SOA」。
讨论「微服务和 SOA 的差别」的意义远不如讨论「微服务和单体系统的差别」更大，因为他们的区别实在有点微妙。此外，互联网近些年的发展，越来越朝去中心化的方向前进了，就像今天的IT工程师不需要像律师、教师那样，需要得到某些机构的认可才能更好的开展工作，这一方面意味着门槛的降低，另一方面也意味着更多的概念没有一个权威的声音来对它进行定义，使得每个人可以根据自己的需求做出不同的调整。
微服务和 SOA 都是这样背景下的产物，并没有一个权威的定义，来说明它们各自包含了什么东西，使用什么的方法进行系统的构建。但是，还是可以从最大的范围来对比它们的不同，当我们今天说出这两个概念时，其区别往往没有那么大，但 SOA 是有一定的历史了，在历史上的 SOA 往往意味着更多的东西，而这些是现在很多人在做架构设计时不会采用的。
说说最终一致性的实现方案
问题的起源在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？
具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。
在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。
强一致当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。
弱一致性系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。
最终一致性弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。
在工程实践上，为了保 ...
怎么考虑数据一致性问题
单体应用的数据一致性想象一下如果我们经营着一家大型企业，下属有航空公司、租车公司、和连锁酒店。我们为客户提供一站式的旅游行程规划服务，这样客户只需要提供出行目的地，我们帮助客户预订机票、租车、以及预订酒店。从业务的角度，我们必须保证上述三个服务的预订都完成才能满足一个成功的旅游行程，否则不能成行。
我们的单体应用要满足这个需求非常简单，只需将这个三个服务请求放到同一个数据库事务中，数据库会帮我们保证全部成功或者全部回滚。
当这个功能上线以后，公司非常满意，客户也非常高兴。
微服务场景下的数据一致性这几年中，我们的行程规划服务非常成功，企业蒸蒸日上，用户量也翻了数十倍。企业的下属航空公司、租车公司、和连锁酒店也相继推出了更多服务以满足客户需求，我们的应用和开发团队也因此日渐庞大。如今我们的单体应用已变得如此复杂，以至于没人了解整个应用是怎么运作的。更糟的是新功能的上线现在需要所有研发团队合作，日夜奋战数周才能完成。看着市场占有率每况愈下，公司高层对研发部门越来越不满意。
经过数轮讨论，我们最终决定将庞大的单体应用一分为四：机票预订服务、租车服务、酒店预订服务、和支付服务。服务各自使用自 ...
说说 CAP 定理、 BASE 理论
CAP 定理2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP 理论正式成为分布式计算领域的公认定理。
CAP 理论为：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
一致性（Consistency）一致性指 “all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。
可用性（Availability）可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。
分区容错性（Partition tolerance）分区容错性指“the system continues to operate despite arbitrary mes ...
如何保证接口的幂等性
当通过调用创建实例接口在负载均衡中创建云服务器时，如果遇到了请求超时或服务器内部错误时，客户端可能会尝试重发请求，这时客户端可以通过提供可选参数 ClientToken 避免服务器创建出比预期要多的实例，也就是通过提供 ClientToken 参数保证请求的幂等性。ClientToken 是一个由客户端生成的唯一的、大小写敏感、不超过 64 个 ASCII 字符的字符串。
如果用户使用同一个 ClientToken 值调用创建实例接口，则服务端会返回相同的请求结果，包含相同的 InstanceId。因此用户在遇到错误进行重试的时候，可以通过提供相同的 ClientToken 值，来确保负载均衡只创建一个实例，并得到这个实例的 InstanceId。
如果用户提供了一个已经使用过的 ClientToken，但其他请求参数不同，则负载均衡会返回 IdempotentParameterMismatch 的错误代码。但需要注意的是，SignatureNonce、Timestamp 和 Signature 参数在重试时是需要变化的，因为负载均衡使用 SignatureNonce 来防止重放攻击， ...
