【微服务】我所理解的微服务架构

1、什么是微服务架构？

微服务架构（Microservice Architecture）是一种架构理念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次（而非组件的类层次）应用六大设计原则。
（1）单一职责原则：
  原义：一个类或者一个方法只完成一件事。
  引申：一个微服务只完成一件事。
（2）开放封闭原则：
  原义：对扩展开放，修改关闭
  引申：每个微服务都很独立，它可以单独修改、升级，甚至被完全替换。
（3）里氏替换原则：
  原义：基类出现的地方，都可以用子类替换。
  引申：微服务后向兼容，新的版本兼容旧的接口。
（4）迪米特法则：
  原义：最少知识原则，一个对象对另一个对象知道的越少越好。
  引申：一个微服务关心的事情很少，就两件事，一是它所订阅的接口，一是它所发布的接口。
（5）依赖倒置原则：
  原义：面向接口编程。
  引申：面向数据接口编程。
（6）接口隔离原则：
  原义：接口要尽量小，不要提供一个大而全的接口。
  引申：不需要暴露系统中的所有服务，根据功能需要，来裁剪和组合服务。

2、微服务的特点

（1）单一职责：一个微服务只完成一件事。
（2）高度自治：一个微服务就是一个独立的实体，可以独立开发、部署。
（3）无状态：每个微服务都是一个无状态的计算节点，可根据需要扩展若干个无差别服务实例。

3、微服务的优点

1、服务规模小
  每个微服务规模都很小（不超过2万行代码），易开发，易维护，易重构。
2、服务可独立开发、扩展和部署
  每个微服务可由不同的团队独立开发、扩展和部署，互不干扰，这大大提高了研发效率。
3、更好的容错性
  微服务可以实现更好的故障隔离。
  例如，某个服务中的内存泄露不影响其它服务，其它服务仍旧可以正常地响应请求。
4、更容易实验和采纳新技术
  微服务架构可以消除对某项技术栈的长期依赖。
  原则上，当开发一个新服务时，开发者可以自由选择适用于这个服务的任何语言和框架。
  这使得使用更好的编程语言和技术重写一项服务变得有可能。

4、微服务的缺点

1、整体复杂度变高
  单个服务的复杂度变低了，但是服务与服务间的通信、接口多了，加上服务治理本身也很复杂，所以整个系统变复杂了。
2、运维成本增加
  部署难度增加，监控难度增加，问题定位成本也增加。
3、人力成本增加
  微服务并没有减少工作量，反而在一定程度上增加了工作量。云环境，服务治理，监控，这些都增加了工作量。

5、微服务治理

1、Spring Cloud全家桶：
  （1）服务发现与注册： Eureka、Consul、Nacos
  （2）负载均衡调用： Ribbon、Spring Cloud Loadbalancer
  （3）熔断器：Hystrix、Spring Cloud Circuit Breaker
  （4）网关：Zuul、Spring Cloud Gateway
  （5）链路追踪：Sleuth
  （6）配置：Config
2、远程通信：HTTP、Websocket
3、消息队列：Kafka、Rabbit、Rocket
4、缓存：Redis
5、数据库：MySQL、Oracle、MongoDB