微服务介绍

一、什么是微服务

• 单体应用的痛点
  • 部署效率低下
  • 团队协作开发成本高
  • 系统高可用性差
• 什么是服务化
  • 把传统的单机应用从本地方法调用，改造成通过RPC、HTTP产生的远程方法调用
  • 把模块从单体应用中拆分出来，独立成一个服务部署
• 微服务是一种架构风格
• 开发单个应用作为一系列小型服务的套件，其中每个服务都运行在自己的进程中，并且通过轻量级的机制实现彼此间的通信，这通常是HTTP资源API
• 这些服务是围绕着业务功能构建的，并且可以通过完全自动化的部署机制进行独立部署
• 这些服务的集中式管理做到了最小化（例如docker相关技术），每一种服务都可以通过不同的编程语言进行编写，并且可以使用不同的数据存储技术。

二、微服务的特点

• 组件以服务形式来提供
• 微服务是产品而不是项目
• 轻量级通信、独立进程
• 分散治理、去中心化治理
• 容错性设计
• 会带来团队组织架构的调整
  • 水平团队组织架构：前端团队、后端团队、DBA团队、测试团队
  • 垂直团队组织架构：支付业务团队、订单业务团队、用户业务团队
• 微服务是要满足一系列的条件和原则，并不是说使用了某个技术或某种框架就是微服务了。微服务中的可用模块非常多，只需要选取一部分非常适合本业务的的模块就行了，这样才算是掌握了微服务的真谛。

三、微服务的优缺点

• 优点
  • 服务简单、便于学习和上手，相对易于维护
  • 独立部署，灵活扩展：可以根据每个服务的吞吐量不同，进行合理和灵活的部署
  • 技术栈丰富：可以在边缘模块尝试新技术.
• 缺点
  • 运维成本过高
  • 接口可能不匹配
  • 代码可能重复
  • 架构的复杂度提高

四、微服务的两大门派

• Spring Cloud：众多子项目（Nexflix为Spring Cloud贡献了很多的组件）
• Dubbo：高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现
• Dubbo提供的能力只是Spring Cloud的一部分子集
• Spring Cloud和Dubbo对比
  • 通信协议上：REST vs RPC
    • RPC缺点：服务提供方与调用方接口依赖方式太强，因为RPC不是一种通用的通信协议
    • Dubbo：服务对平台敏感，难以简单复用。Dubbo如果想要对外提供服务，必须额外实现一层代理把RPC接口转换为HTTP才能对外发布。
  • 文档质量对比
    • Dubbo的文档可以说在国内开源框架中算是一流的了，提供了中文和英文两种版本
    • Spring Cloud文档体量大，更多是偏向整合，更深入的使用方法还是需要查看其整合组件的详细文档
  • Spring Cloud类似于品牌机，Dubbo类似于组装电脑

五、微服务的拆分

• 什么时候进行服务化拆分
  • 第一阶段的主要目标是快速开发和验证想法
  • 进一步增加更多的新特性来吸引更多的目标用户
  • 同时进行开发的人员超过10人，这时候就该考虑进行服务化拆分了
• 不适合拆分的情况
  • 小团队，技术基础较薄弱
  • 流量不高，压力小，业务变化也不大
  • 对延迟很敏感的低延迟高并发成本，因为微服务有网络通信延迟成本
• 服务化拆分的两种姿势
  • 纵向拆分
    • 例如按照评论、消息通知、个人主页等进行拆分
  • 横向拆分
    • 按照公共领域拆分，如评论、消息通知、个人主页等要用到用户服务，则可以把用户服务拆分出来，以提供给各个模块
  • 综合业务综合分析（建议每个开发人员所负责的服务不要超过3个）

六、微服务扩展

• x轴 - 水平复制：把整个系统作为整体直接重新部署几套，然后在上流部署一个负载均衡器。
• y轴 - 功能解耦：指的是微服务的拆解。
• z轴 - 数据分区：当系统足够大的时候，数据库也是需要分开独立的，因为把所有内容都放到一个数据库中，它的压力会特别大，而且存储空间也会不够。如可以把VIP用户从普通用户中拆分出来，独立地提供资源，这样会使得VIP用户的访问速度更快。再比如业务很庞大，用户数据是用手机注册的，那么就可以以手机号的尾数来作为数据拆分的标准。通过数据分区，可以进一步提高系统的可用性和性能。
• 自动按需扩展
  • 根据CPU负载程度、特定时间（比如周末）、消息中间件的队列长度、业务具体规则、预测等来决定是否扩展。
  • 自动分配一个新的服务实例是，提高可用性。
  • 提高了可伸缩性（双11之后，自动减少服务器）。
  • 具有最佳使用率，节省成本。

七、微服务重要模块

• 服务描述：是HTTP服务还是其他类型的服务，如果是HTTP服务，那么对应的接口的怎么规定的、返回的是什么内容等等。
• 注册中心：不注册的话，消费者不知道从哪找到该服务。
• 服务框架：采用的是TCP还是UDP？采用的是HTTP协议还是其他的协议？传输用什么方式？是同步的还是异步的？是单链接还是多路复用。数据是否需要压缩？压缩的话采用什么格式？如何提高网络利用率？是采用JSON序列化还是Java对象序列化？这一系列的内容由服务框架进行统一。
• 负载均衡：服务会有很多个，不能一直调用某一个服务，使得其他服务一直处于空闲状态，浪费资源。
• 熔断和降级：服务多了难免会有某个服务发生故障，为了保证整体的可用性，不能因为某个服务无法提供服务就导致整个崩盘。应该要实现的是虽然某个服务不能提供服务，但还是有某些保底策略。
• 网关：把用户所有的请求都找到网关，由网关进行下一步的分发。网关还能进行统一的转换、统一的权限校验、过滤器设置等。