【微服务】一篇文章带你打开微服务大门
微服务
- 微服务简介
- 架构风格
- 开发框架
- 使用场景
- 微服务架构特点
微服务简介
微服 务架构是一种使用一组微服务来开发单体应用的方法，每个微服务运行 在自己的进程中，并通过轻量级设备与HTTP协议的API进行通信。
这些 微服务基于业务模块进行划分，每一个业务功能对应一个微服务，并能 够通过自动化部署机制来独立部署。
这些微服务可以使用不同的编程语 言以及不同的数据存储技术来实现，并保持最低限度的集中式。
架构风格
微服务的英文名称是Microservice，它的架构模式就是将整个Web应 用组织为一系列的Web微服务。这些Web微服务可以独立地编译及部 署，并通过各自暴露的API接口相互通信。它们彼此相互协作，作为一 个整体为用户提供功能，且可以独立地进行扩充。
微服务从单体应用架构演变而来，是架构风格(服务微化)的改 变。微服务的特点是:
-
一个应用应该是一组小型服务;
-
可以通过 HTTP的方式进行沟通;
-
每一个功能元素都是一个可独立替换、可独 立升级的软件单元。
实现微服务的关键除了微服务本身，系统还要提供一套基础的架构，这套架构使得微服务可以独立地部署、运行、升级。
这套架构还要让微服务与微服务之间在结构上为“松耦合”，而在功能上则 表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一 的日志和审计方法，统一的调度方式，统一的访问入口等。
微服务的目的就是有效地拆分应用，实现敏捷开发和部署。
开发框架
目前微服务的开发框架，最常用的有以下4种:
- Spring Cloud:(现在非常流行的微服务架构，与Spring无缝对接)。
- Dubbo (阿里巴巴开源的基于RPC的服务框 架)。
- Dropwizard (关注单个微服务的开 发)。
- Consul 微服务的模块。
使用场景
微服务架构需要的功能或使用场景:
- 我们需要把整个系统根据业务拆分成几个子系统。
- 每个子系统可以部署多个应用，多个应用之间需要使用负载均衡。
- 需要一个服务注册中心，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务并运用一定的策略来实现的。
- 所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置、网关来判断一个URL请求由哪个服务来处理。请求转发到服务上的时候也使用负载均衡。
- 服务之间有时候也需要相互访问。例如，有一个用户服务， 而其他服务在处理一些业务的时候，要获取这个用户服务中的用户数据。
- 需要一个断路器，以便及时处理服务调用时的超时和错误， 防止由于其中一个服务的问题而导致整体系统的瘫痪。
- 还需要一个监控功能，监控每个服务调用花费的时间等。
微服务架构特点
微服务使用轻量级HTTP、REST或Thrift API进行通 信，其特点是:
- 把系统的服务层完全独立出来，有利于资源的重复利用，可 提高开发效率。
- 微服务遵守单一原则。
- 微服务与微服务之间的调用使用RESTful轻量级调用。
优点：
- 微服务拆分更细，有利于资源的重复利用，可提高开发效率。
- 可以更加精准地针对某个服务做方案。
- 微服务去中心化，使用RESTful轻量级通信协议比使用ESB企业服务总线更容易维护。
- 适应市场更容易，产品迭代周期更短。
缺点：
- 微服务数量多，服务治理成本高，不利于系统维护。
- 分布式系统架构且是微服务架构，技术成本高(容错、分布式 事务等)，对团队挑战高。
微服务架构虽然有很多优点，但并不是解决所有问题的万金油，一般需要满足具有自己
特点的使用场景。