微服务概述

什么是微服务

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

业界大牛马丁.福勒（Martin Fowler）这样描述微服务：
原论文地址：https://martinfowler.com/articles/microservices.html
译文（中文）版：https://martinfowler.cn/articles/microservices.html

就目前而言，对于微服务业界并没有一个统一的、标准定义（While there is no precise definition ot this architectural style）

但通常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程中，微服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务去构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文 ，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

---

技术角度来理解
微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理进程，类似进程的概念，能够自行单独启动或者销毁，拥有自己独立的数据库。

微服务与微服务架构

微服务
强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义的看，可以看做Eclipse里面的一个个微服务工程/或者Module

微服务架构
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体的业务进行构建，并且能够独立的部署到生产环境、类生产环境。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务与微服务架构的优缺点

优点

• 每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或者业务需求。
• 开发简单、开发效率高，一个服务可能就是专一的只干一件事。
• 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或者部署阶段都是独立的。
• 微服务能使用不同的语言开发。
• 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jeekins、hudson、bamboo。
• 微服务易于被一个开发人员理解，修改与维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
• 微服务允许你利用融合最新的技术
• 微服务知识业务逻辑的代码，不会和HTML、css或者其他界面组件混合。
• 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一的数据库。

缺点
1.开发者需要应对创建分布式系统所产生的额外的复杂因素
l 目前的IDE主要面对的是单体工程程序，无法显示支持分布式应用的开发
l 测试工作更加困难
l 需要采用服务间的通讯机制
l 很难在不采用分布式事务的情况下跨服务实现功能
l 跨服务实现要求功能要求团队之间的紧密协作
2.部署复杂
3.内存占用量更高

内部服务之间的通信方式有两种：
1、基于HTTP协议的同步机制(REST、RPC);
2、基于消息队列的异步消息处理机制(AMQP-based message broker)。

微服务架构的好处
1.单个服务很容易开发、理解和维护。
2.这种架构使得每个服务都可以有专门开发团队来开发。
3.微服务架构模式是每个微服务独立的部署。
4.微服务架构模式使得每个服务独立扩展。

微服务架构的不足
微服务应用是分布式系统，由此会带来固有的复杂性。
服务地址目录，服务健康度，部署困难，服务依赖问题，数据库分区问题。

---

本文来自 varyall 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/varyall/article/details/78905332?utm_source=copy

微服务技术栈有哪些

• 服务开发：spring、springBoot、springMVC
• 服务配置与管理：Netflix公司的Archaius、阿里的Diamond等
• 服务注册与发现：Eureka、Consul、Zookeeper等
• 服务调用：Rest、RPC、gRPC
• 服务熔断器：Hystrix、Envoy等
• 负载均衡：Riboon、Nginx等
• 服务接口调用（客户端调用服务的简化工具）Feign等
• 消息队列：Kafka、RabbitMQ、ActiveMQ等
• 服务路由（API网关）：Zuul等
• 服务监控：Zabbix、Nagios、Metrics、Spectator等
• 全链路追踪：Zipkin、Brave、Dapper等
• 服务部署：Docker、OpenStack、Kubernetes等
• 数据流操作开发包：SpringCloud Stream（封装Redis、Rabbit、Kafka等发送接收消息）
• 事件消息总线：SpringCloud Bus

为什么选择SpringCloud作为微服务架构

选型依据

• 整体解决方案和框架成熟度
• 社区热度
• 可维护性
• 学习曲线

当前各大IT公司用的微服务架构有哪些

• 阿里Dubbo/HSF
• 京东JSF
• 新浪微博Motan
• 当当网Dubbox

各微服务框架对比