微服务拆分规范

一、微服务拆分规范

微服务拆分之后,工程会比较的多,如果没有一定的规范,将会非常混乱,难以维护。

1、高内聚、低耦合

紧密关联的事物应该放在一起,每个服务是针对一个单一职责的业务能力的封装,专注做好一件事情(每次只有一个更改它的理由)。如下图:有四个服务A、B、C、D,但是每个服务职责不单一,A可能在做B的事情,B又在做C的事情,C又同时在做A的事情,通过重新调整,将相关的事物放在一起后,可以减少不必要的服务。

图1,高内聚、低耦合

通用拆分方式:

  1. 先按业务领域拆,如社区、用户、商城、慢病、工单,如果有相同功能需要聚合,则进行下沉(垂直)。
  2. 再按功能定位拆(水平),如商城业务复杂度提高之后可进一步拆分为商品、订单、物流、支付。
  3. 按重要程度拆,区分核心与非核心,如订单核心,订单非核心。

Continue reading "微服务拆分规范"

今日头条Go建千亿级微服务的实践(转)

今日头条当前后端服务超过80%的流量是跑在 Go 构建的服务上。微服务数量超过100个,高峰 QPS 超过700万,日处理请求量超过3000亿,是业内最大规模的 Go 应用。

Go 构建微服务的历程

在2015年之前,头条的主要编程语言是 Python 以及部分 C 。随着业务和流量的快速增长,服务端的压力越来越大,随之而来问题频出。Python 的解释性语言特性以及其落后的多进程服务模型受到了巨大的挑战。此外,当时的服务端架构是一个典型的单体架构,耦合严重,部分独立功能也急需从单体架构中拆出来。

为什么选择 Go 语言?

Go 语言相对其它语言具有几点天然的优势:

  • 语法简单,上手快
  • 性能高,编译快,开发效率也不低
  • 原生支持并发,协程模型是非常优秀的服务端模型,同时也适合网络调用
  • 部署方便,编译包小,几乎无依赖

当时 Go 的1.4版本已经发布,我曾在 Go 处于1.1版本的时候,开始使用 Go 语言开发后端组件,并且使用 Go 构建过超大流量的后端服务,因此对 Go 语言本身的稳定性比较有信心。再加上头条后端整体服务化的架构改造,所以决定使用 Go 语言构建今日头条后端的微服务架构。

2015年6月,今日头条开始使用 Go 语言重构后端的 Feed 流服务,期间一边重构,一边迭代现有业务,同时还进行服务拆分,直到2016年6月,Feed 流后端服务几乎全部迁移到 Go。由于期间业务增长较快,夹杂服务拆分,因此没有横向对比重构前后的各项指标。但实际上切换到 Go 语言之后,服务整体的稳定性和性能都大幅提高。 Continue reading "今日头条Go建千亿级微服务的实践(转)"

etcd: 从应用场景到实现原理的全方位解读

随着CoreOS和Kubernetes等项目在开源社区日益火热,它们项目中都用到的etcd组件作为一个高可用强一致性的服务发现存储仓库,渐渐为开发人员所关注。在云计算时代,如何让服务快速透明地接入到计算集群中,如何让共享配置信息快速被集群中的所有机器发现,更为重要的是,如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群,已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音,本文将从etcd的应用场景开始,深入解读etcd的实现方式,以供开发者们更为充分地享用etcd所带来的便利。 Continue reading "etcd: 从应用场景到实现原理的全方位解读"

安装gRPC开发环境

gRPC开发源码包安装

安装官方安装命令:

是安装不起的,会报:

原因是这个代码已经转移到github上面了,但是代码里面的包依赖还是没有修改,还是 google.golang.org 这种地址,

所以不能使用go get的方式安装,正确的安装方式:

Continue reading "安装gRPC开发环境"

微服务常见架构方案及基础框架

微服务(MicroServices)架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:

一个微服务架构有哪些技术关注点(technical concerns)?

需要哪些基础框架或组件来支持微服务架构?

这些框架或组件该如何选型? Continue reading "微服务常见架构方案及基础框架"

分布式系统的Raft算法

过去,Paxos一直是分布式协议的标准,但是Paxos难于理解,更难以实现,Google的分布式锁系统Chubby作为Paxos实现曾经遭遇到很多坑。

来自Stanford的新的分布式协议研究称为Raft,它是一个为真实世界应用建立的协议,主要注重协议的落地性和可理解性。

在了解Raft之前,我们先了解Consensus一致性这个概念,它是指多个服务器在状态达成一致,但是在一个分布式系统中,因为各种意外可能,有的服务器可能会崩溃或变得不可靠,它就不能和其他服务器达成一致状态。这样就需要一种Consensus协议,一致性协议是为了确保容错性,也就是即使系统中有一两个服务器当机,也不会影响其处理过程。

为了以容错方式达成一致,我们不可能要求所有服务器100%都达成一致状态,只要超过半数的大多数服务器达成一致就可以了,假设有N台服务器,N/2 1 就超过半数,代表大多数了。

Paxos和Raft都是为了实现Consensus一致性这个目标,这个过程如同选举一样,参选者需要说服大多数选民(服务器)投票给他,一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同。

Continue reading "分布式系统的Raft算法"

CAP原理和BASE思想

分布式领域CAP理论
Consistency(一致性): 数据一致更新,所有数据变动都是同步的;
Availability(可用性):好的响应性能,但往往一致性要求越高的系统,可用性越低;
Partition tolerance(分区容错性):可靠性,分区之后也能够保证集群的只能正常行使,往往是分布式系统中必须保证的一点;

定理:任何分布式系统只可同时满足二点,没法三者兼顾。
忠告:架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。

Continue reading "CAP原理和BASE思想"

JSON-RPC、XML-RPC、SOAP三者的关系

JSON-RPC规范:http://json-rpc.org/wiki/specification

XML-RPC规范:http://www.xmlrpc.com/spec

SOAP规范:http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383487

参考:http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm

三者都是为了实现RPC中的消息交换,并且都没有定义传输协议。不过为了更方便在网络中传输,而且由于HTTP的无状态性,都使得HTTP为这三者的常用的传输协议。下面例子也是基于HTTP协议的

XML-RPC和SOAP都是基于XML格式的消息交换:

XML-RPC非常简单,定义了几种基本类型、匿名结构体、匿名数组;

SOAP除了基本类型、命名结构体、命名数组以外,还可以自定义类型,能使用多态的方法调用方式

而JSON-RPC是基于JSON格式的消息交换,JSON比XML更加轻巧,并且非常容易在页面JS中使用,其他特点与XML-RPC类似

下面是使用这几种协议发送请求的例子:

XML-RPC

Xhtml代码
  1. POST /RPC2 HTTP/1.0  
  2. User-Agent: Frontier/5.1.2 (WinNT)  
  3. Host: betty.userland.com  
  4. Content-Type: text/xml  
  5. Content-length: 181  
  6.   
  7.   
  8.   
  9. <?xml version="1.0"?>  
  10. <methodCall>  
  11.    <methodName>examples.getStateName</methodName>  
  12.    <params>  
  13.       <param>  
  14.          <value><i4>41</i4></value>  
  15.          </param>  
  16.       </params>  
  17.    </methodCall>  

SOAP:

Xhtml代码
  1. POST /StockQuote HTTP/1.1  
  2. Host: www.stockquoteserver.com  
  3. Content-Type: text/xml; charset="utf-8"  
  4. Content-Length: nnnn  
  5. SOAPAction: "Some-URI"  
  6.   
  7. <SOAP-ENV:Envelope  
  8.   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"  
  9.   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>  
  10.    <SOAP-ENV:Header>  
  11.        <t:Transaction  
  12.            xmlns:t="some-URI"  
  13.            SOAP-ENV:mustUnderstand="1">  
  14.                5  
  15.        </t:Transaction>  
  16.    </SOAP-ENV:Header>  
  17.    <SOAP-ENV:Body>  
  18.        <m:GetLastTradePrice xmlns:m="Some-URI">  
  19.            <symbol>DEF</symbol>  
  20.        </m:GetLastTradePrice>  
  21.    </SOAP-ENV:Body>  
  22. </SOAP-ENV:Envelope>  

JSON:

Javascript代码
  1. --> { "method": "echo", "params": ["Hello JSON-RPC"], "id": 1}  
  2. <-- { "result": "Hello JSON-RPC", "error": null, "id": 1}