什么是微服务
微服务和单体应用恰恰相反，把各个模块拆分成不同的项目，每个模块都只关注一个特定的业务功能，发布时每一个项目都是一个独立的包，运行在独立的进程上。微服务应该足够小，小到即使全部重写也不需要过多的时间。微服务化是SOA（Service-Oriented Architecture，面向服务的架构）的一种方法。微服务架构的核心目标是把复杂问题简单化，通过服务划分，把一个完整的系统拆分成多个高内聚、低耦合的小的子系统。使每个子系统可以独立的运行、升级和测试。然后再通过一些集成手段将这些子系统组合在一起，对外提供完整功能的过程。
微服务设计原则
- 单一职责原则： 每个服务应该只关注特定的某一类业务。
- 服务自治原则： 每个服务具备独立的业务能力、依赖和运行环境，与其他服务高度解耦，每个服务都应当可以独立运行，不应该依赖其他服务。
- 轻量级通信机制： 应该使用轻量级的、语言无关的、跨平台的协议，如REST、MQTT等。
微服务的技术栈
| 微服务条目 | 落地技术 |
|---|---|
| 服务开发 | SpringBoot,Spring,SpringMVC |
| 服务配置与管理 | Netflix公司的Archaius、阿里的Diamond等 |
| 服务注册与发现 | Eureka、Consul、Zookeeper等 |
| 服务调用 | Rest、RPC、gRPC |
| 服务熔断器 | Hystrix、Envoy等 |
| 负载均衡 | Ribbon、Nginx等 |
| 服务接口调用（客户端调用服务的简化工具） | Feign等 |
| 消息队列 | Kafka、RabbitMQ、ActiveMQ等 |
| 服务配置中心管理 | SpringCloudConfig、Chef等 |
| 服务路由（API网关） | Zuul等 |
| 服务监控 | Zabbix、Nagios、Metrics、Specatator等 |
| 全链路追踪 | Zipkin、Brave、Dapper等 |
| 服务部署 | Docker、OpenStack、Kubernetes等 |
| 数据流操作开发包 | SpringCloud Stream(封装与Redis，Rabbit，Kafka等发送接收消息) |
| 事件消息总线 | SpringCloud Bus |
微服务的优点：
- 易于开发，可维护性高： 一个服务只会关注一个特定的业务模块，代码比较少，可维护性就高。
- 发布风险低： 发布单个服务不需要重新发布整个应用。
- 技术栈不受限（异构）： 微服务之间通过轻量级的通信机制进行通信，比如RESTful API，因此不同项目可以随意选择合适的技术来实现。
- 按需伸缩： 可以针对特定的服务，结合业务特点分配不同的硬件规格。
微服务的缺点：
- 运维要求高： 对于单体应用只要部署一个服务，微服务化后可能需要部署几十几百个服务.
- 分布式固有的复杂性： 开发人员需要考虑分布式事务、系统的容错性等，比如服务A的某个接口依赖服务B，通过RESTful API调用服务B的接口但发生了错误，需要提供重试等机制。
- 修改接口成本增加： 修改接口本就是一件繁琐的事，微服务化后成本更高，因为各个服务之间只通过轻量级通信机制访问，耦合度比较低，需要排查哪些服务的接口受到了影响，而在单体应用中通常只是方法间的依赖，如果修改了某个方法的签名，那么在编译时就会报错。
- 重复劳动： 当一个单体应用微服务化后，不同的服务之间会有重复代码产生，比如Gradle脚本、Maven依赖都非常类似，使用到的某些函数每个服务都造了一遍等，如果都是用同一种语言实现的还能用共享库解决，如果有多种语言那就难以避免重复劳动了。
- 数据一致性
- 系统集成测试：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。
解决方案：
- 服务注册与发现，服务监控，日志监控，调用追踪
- 服务容错：需要引入熔断、隔离、限流和降级、超时机制等服务容错机制来保证服务持续可用性
- 服务安全
参考：
https://blog.csdn.net/disdouble/article/details/83271917