360搜索在微服务架构下的技术平台实践（二） -- 微服务架构

什么是微服务？

其实最近两年微服务这个概念挺火的，那其实究竟什么是微服务呢？

微服务其实是一种架构风格、一种约定。就和我们开发中使用的设计模式是一个道理。
每个微服务仅关注于完成一件任务
每个微服务独立部署，互不干预
一个应用由一个或多个微服务组成

把我们上一文中的单体架构，拆分成微服务的结构，那么应该是如下图：

这里我们将每个功能拆分为一个单独的服务，有自己的web容器，然后通过gateway连结起来，对外提供服务。用户只和Gateway打交道，有点像是反向代理的感觉。

但这里的拆分并不一定非得变为这样，你可以拆得更细，或者是更粗，视你业务情况而定，不要脱离业务谈架构

这些服务之间如何通信？

我们将一个商城应用拆分为如上图所示后。当用户购买一件商品时，要涉及到支付、修改购物车信息、修改商品库存、发送短信通知 等多个服务。
当我们将整个单体架构拆为这样的微服务时，他们之间如何通信和协作呢？

通信方式
通信方式分为同步、异步两类
同步：
   P2P
   Gateway

P2P方式中，服务之间直接相互调用，每个服务都对外开放自己的API并调用其他服务的接口
Gateway方式中，服务之间相互调用也通过API网关

P2P优点：少一次网络IO
P2P缺点：无法做流量控制、无法记录具体调用情况
Gateway调用方式的优缺点正好与之相反

异步：
   消息中间件

一般用于下游服务执行时间不可控，或与调用者接下来逻辑无关联的情况

一般同步通信下我们使用 HTTP RESTful 方式，异步下我们使用消息中间件（如消息队列、发布/订阅等）

一般常用的消息格式为 JSON

如何划分你的团队/服务 规模

2P2W 原则：

2 Pizza – 负责一个服务的团队，不要让两个Pizza不够分，也就意味着最好不要超过6个人，如果你服务粒度很小，那么2-3个人也不是不行

2 Week – 一个团队对其所负责的服务，如果要进行重构，时间不要超过2周，也就意味着太复杂或是工程太浩大的服务，需要考虑再次进行拆分

微服务的优点&挑战

优点

简单
        一个服务只关注一个功能
扩容灵活
        哪个服务需要扩容，就给哪个服务单独做扩容
技术栈灵活
        各团队可以自行选择最佳的技术栈来进行开发，例如Go支撑高性能服务，           PHP支持普通业务
持续集成友好
        允许我们在频繁发布不同服务的同时，保持系统其他服务的可用性

挑战

需要技术积累
运维成本
        需要构建/测试/部署/运行 数十个甚至更多的服务。不同的服务有不同的技          术栈，运维人员难以全部精通，开发人员才是运维该服务的专家
人才稀缺
        具有较强的DevOPS能力的人才稀缺。
分布式系统带来的问题
        分布式事务、网络延迟/波动 等。
难以全面测试
        需要自动化流程，不论是自动化测试还是自动集成，一般常用的质量保证            手段是上线后通过监控发现生产环境的异常，进而快速回滚或采取行动

划重点

每个微服务是一个单体架构
每个微服务专注于一个功能
数据需要去中心化，每个微服务只能访问自身的数据库
一套微服务组合起来，对外提供一个完整的服务