服务治理好文章{转}

微服务架构是由Martin Fowler在他这篇microservices博客中提出来的，与之对立的是monolithic架构。

monolithic架构概念 vs. 微服务架构概念

    monolithic架构指的是应用被以单一单元构建。好比一个小型订餐网站包含菜品展现、下订单、在线支付等业务功能模块，该网站的后端系统应用实现了全部这些业务功能。

    而微服务架构则是由一组微服务组成的架构模式。每一个微服务都是一个可独立部署的完整系统。一组微服务组成微服务层（注意这里的服务层不一样于monolithic架构中的服务层，那个是单系统中的功能模块分层）。微服务层上面通常是应用层，应用层经过组合使用微服务层的各个微服务而向外提供接口（好比HTTP API接口）。各个微服务能够经过RPC接口供应用层调用，好比利用Thrift、Avro。

微服务拆分方法

    微服务架构中的微服务通常按照业务功能来拆分，将关联性较强的业务拆成一个微服务，好比上面订餐网站能够拆分红用户服务、订单服务、菜品服务、支付服务等。具体来讲通常根据业务实体名词如订单、用户或者业务动做如登陆、下载等来拆分。

数据集成 vs. 服务集成

    数据集成是一种比较传统的系统集成方式，其中心是数据。好比交易系统会操做订单表和用户表，好比生成订单。而短信通知系统也会访问订单表和用户表，根据订单的状态来发出不一样的短信通知给用户：好比给金额较大的订单对应的用户发一些促销活动短信，给一些未完成订单的用户发短信提醒其完成订单。这就是一种数据集成方式，交易系统和短信通知系统依靠订单表和用户表进行集成。这种集成方式的优势在于实现简单，缺点有下面几条：

• 业务数据库负担较大，由于多个系统都访问同一个数据库的同几张表

• 安全性，交易系统能够修改订单表中的订单状态是理所固然的事，但因为短信通知系统也能够直接访问订单表，可能致使一些意想不到的问题

• 扩展性问题：交易系统若是之后想把订单表从RDBMS迁到HBase可能就没那么容易了，由于还有不少其余系统也依赖于订单表，真可谓牵一发而动全身；或者各个系统可能擅自作主给表增减字段，都会带来很差后果

• DAO代码重复，若是交易系统和短信通知系统由两个不一样部门的团队开发，那么每一个系统中都会有针对订单表和用户表的DAO代码

    服务集成则打破了数据集成模式，再也不以数据为中心集成各系统。微服务架构自然就拥抱服务集成方式。若是用服务集成方式从新设计上面的交易系统和短信通知系统，那么就会提出两个微服务：用户微服务，负责对用户信息进行管理（具体底层是否真的操做关系数据库表，外部已经不关心，即外部不知道用户信息是存在MySQL、Redis仍是两者都有，也不须要知道）；和订单微服务，负责对订单信息进行管理。交易系统和短信通知系统都被提取到更上一层的应用层，他们分别调用用户微服务和订单微服务完成任务。这样用户数据状态的变化和订单数据状态的变化将再也不同时受控于交易系统和短信通知系统，而只由用户微服务和订单微服务控制。

微服务与微服务之间相互调用

    通常避免微服务直接调用另一个微服务，尤为忌讳两个微服务相互调用，若是存在两个微服务相互调用的场景，那么得慎重衡量下微服务拆分是否合理。

    固然某些状况没法避免微服务之间相互调用，这时候咱们通常能够采用两种方式实现：

• 消息队列

• 消息总线

monolithic架构与微服务架构各自优缺点

    除了上面提到的一些优缺点外。下面再总结下两种架构的各自优缺点。

    首先看monolithic架构，它的优势是：部署方便，只须要部署一份代码。但它的缺点有不少：

• 代码庞杂，理解困难，新人上手也困难

• 维护困难，通常一个monolithic架构应用得由一个团队维护，若是应用越大，则维护的人越多，团队管理成本也越高，团队效率也会越低下（3-5人是最佳团队规模）

• 启动通常较慢

• 持续部署困难：每一次小改动都须要从新部署整个应用

• 技术堆栈固化：尝试新技术的代价过高

• 扩展困难：应用某些部分偏IO密集型、某些部分却偏CPU密集型，但应用却只部署在一台机器上，很难用单一硬件来知足应用各部分对硬件资源的不一样要求

    微服务架构的优势天然与上面的缺点相反，列举三条：

• 每一个微服务功能简单，代码量也很少，新人上手容易

• 每一个微服务能够由不一样团队开发，每一个微服务通常由1-3人开发维护

• 系统稳定性加强，单个服务的失效不会影响其余服务，能够必定程度实现服务降级

• 容易尝试技术创新，甚至每一个微服务均可以采用不一样的编程语言编写，只要对外提供约定好的接口就行

    但微服务架构也有缺点，按照我我的理解的严重程度由高到低排列以下：

• 运维成本高：原来一个应用一个进程，如今被拆分红微服务后可能有十几个进程，而且每一个微服务都须要独立部署

• 测试成本高：微服务架构带来的是一个分布式系统，分布式系统的测试比单系统测试更复杂

• 微服务升级带来的接口不向后兼容问题

• 每一个微服务开发者都须要关注微服务开发、集成、测试、部署、上线完整流程

    为了应对微服务升级带来的接口不向后兼容问题，通常能够对接口升级作一些约定以保证接口向后兼容，假设微服务采用Thrift接口开放给应用层，那么约定以下：

通常接口升级只容许下面几种状况（这种状况可以保证Thrift服务端二进制代码向后兼容客户端，
即Thrift服务端由V1.0.9升级到V1.1.0，客户端依然可使用V1.0.9 Thrift服务端对应的Stub
代码）：
> 增长新接口方法或者新结构体（Struct）
> 在接口方法参数后面增长非必须参数
> 为结构体（Struct）增长非必须参数
> 修改返回值类型为void的接口方法，使其返回值类型为任意其余类型
> 删除接口方法签名中的throw
> 从结构体中删除field
> 重命名结构体
> 修改命名空间

不容许的状况包括：
> 删除或者重命名接口方法
> 修改非void返回值类型接口方法的返回值类型
> 修改接口方法参数类型
> 为非void返回值类型接口方法添加throw
> 经过Thrift接口开放给外部的系统在升级后必须升级pom.xml中的版本号，同时对应的inf接口
  项目的版本号也要跟着升级