微服务
微服务与微服务架构
什么是微服务
微服务是最近几年流行的一种架构思想。由Martin Fowler在2014年提出的
原文：https://martinfowler.com/articles/microservices.html
翻译：https://blog.csdn.net/jason_wang1989/article/details/88321698
“微服务架构”一词是在过去几年里涌现出来的，它用于描述一种独立部署的软件应用设计方式。这种架构方式并没有非常明确的定义，但有一些共同的特点就是围绕在业务能力、自动化布署、端到端的整合以及语言和数据的分散控制上面。
总之，微服务这种架构风格就是把一组小服务演化成为一个单一的应用的一种方法。每个应用都运行在自己的进程中，并通过轻量级的机制保持通信，就像HTTP这样的API。这些服务要基于业务场景，并使用自动化布署工具进行独立的发布。可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。
官方话不好理解，用我们的技术来理解
微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地解耦，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。
微服务与微服务架构
微服务
微服务强调的是单个服务的大小，关注的是某一个点，具体解决某一个问题/提供落地对应服务的一个服务应用 ；
狭义的看，可以看成 IDEA里面的一个个微服务工程或者Module，他具体是使用spring boot开发的一个小模块，专业的事交给专业的模块做。
微服务架构
一种全新的架构形式，Martin Fowler在2014年提出的。
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小服务，服务之间互相协调，为用户提供最终价值，每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相协作，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中，另外尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的言语，工具对其进行构建。
微服务优缺点
优点：
-
每个服务足够内聚，足够小，代码容易理解；这样能够聚焦一个指定的业务功能或业务需求
-
开发简单、开发效率提高，一个服务可能就是专一的做一个业务功能
-
微服务能够被小团队单独开发，2-5人的开发人员组成
-
微服务是松耦合的，具有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
-
微服务能够使用不同的语言开发
-
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins,Hudson,bamboo
-
*微服务只是业务逻辑的代码，不会和“HTML、CSS”或其他的界面组件混合；
-
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库
缺点：
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度，随着服务的增加，运维的压力也在增大
- 系统部署依赖
- 服务之间通信成本
- 数据一致性
- 系统集成测试
- 性能监控
微服务技术栈有哪些
| 微服务条目 | 落地技术 |
|---|---|
| 服务开发 | Spring Boot、Spring、SpringMVC |
| 服务配置和管理 | Netflix公司Archaius”、阿里的“Diamond”等 |
| 服务注册与发现 | Eureka、Consul、Zookeeper |
| 服务调用 | Rest/RPC、GRPC |
| 服务熔断器 | Hystrix、Envoy |
| 负载均衡 | Ribbon、Nginx |
| 服务接口调用（客户端调用服务的简化工具） | Feign |
| 消息队列 | Kafka、RabbitMQ、ActiveMQ |
| 服务配置中心 | Chef、SpringCloudConfig |
| 服务路由（API网关） | Zuul |
| 服务监控 | Zabbix、Zagios、Metrics |
| 全链路追踪 | Zipkin、Brave、Dapper |
| 服务部署 | Docker、OpenStack、Kubernetes |
| 数据流操作开发包 | SpringCloud Stream（封装与Redis、Rabbit、Kafka） |
| 事件消息总线 | SpringCloud Bus |
为什么选择SpringCloud微服务架构
1、选型依据
- 整体解决方案和框架熟练度
- 社区热度
- 可维护性
- 学习曲线
2、当前各大IT公司用的微服务架构
- 阿里：Dubbo、HSF
- 京东：JSF
- 新浪：Motan
- 当当：Dubbox
- 等等
3、各微服务框架对比
| 功能点/服务框架 | SpringCloud | Motan | gRPC | Thrift | Dubbo |
|---|---|---|---|---|---|
| 功能定位 | 完整的微服务架构 | RPC框架，整合了ZK或Consul，实现了集群环境的基本服务注册/发现 | RPC框架 | RPC框架 | 服务框架 |
| 支持Rest[HTTP] | 是【Ribbon支持多种可插拨的序列化选择】 | 否 | 否 | 否 | 否 |
| 支持RPC[远程调用] | 否 | 是[Hession2] | 是 | 是 | 是 |
| 支持多语言 | 是 【Rest】 | 否 | 是 | 是 | 否 |
| 服务注册和发现 | 是 【Eureka 服务注册表，Karyon服务端框架支持服务自注册和健康检查】 | 是 zookkeeper | 否 | 否 | 是 |
| 负载均衡 | 是 【服务端 Zuul + 客户端Ribbon，Zuul服务，动态路由，云端负载均衡 Eureka(针对中间层服务器)】 | 是【客户端】 | 否 | 否 | 是【客户端】 |
| 配置服务 | 是【Netflix+Archaius，SpringCloud Config Server 集中配置】 | 否 | 否 | 否 | 否 |
| 服务调用链监控 | 是【Zuul提供边缘服务，API网关】 | 否 | 否 | 否 | 否 |
| 高可用/容错 | 是【服务端Hystrix+客户端Ribbon】 | 是【客户端】 | 否 | 否 | 是【客户端】 |
| 典型应用案例 | 是【Netflix】 | 新浪 | 谷歌 | 否 | |
| 社区活跃程度 | 高 | 一般 | 不高 | 一般 | 低 |
| 学习难度 中等 | 底 | 高 | 高 | 底 | |
| 文档丰富度 | 高 | 一般 | 一般 | 一般 | 高 |
| 其他 | Spring’Cloud Bus 为我们的应用程度带来了许多管理端点 | 支持降级 | Netflidx内部在开发集成gRPC | IDL自定义 | 实践公司比较多 |
