SpringCloud与微服务Ⅱ --- 微服务概述
1) Martin Fowler论文对微服务的阐述(中文版)
2) 对单一应用进行拆分
3) 每一个独立的应用都有一个独立的进程
4) 拥有自己独立的数据库
5) 微服务化的核心就是讲传统的一站式应用，根据业务拆分成一个一个的服务,彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务处理一件事,从技术角度就是一种小而独立的处理过程,类似进程的概念,能够自行单独启动或销毁,拥有自己的数据库。
二.微服务与微服务架构
2.1 微服务架构
1) 类似于eclipse工具里面用maven开发的一个个独立的module,具体是使用springboot开发的一个小模块,一个模块就做一件功能。
2) 强调是整体，每一个个体完成一个具体的任务或者功能，把一个个的个体拼接起来，组成一个整体并对外暴露服务。
3) 微服务架构是一种架构模式,它提倡将单一的应用程序划分成一组小的服务,服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制。对具体的一个服务而言，应根据业务的上下文，选择合适的语言、工具对其进行构建。
2.2 微服务
强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义地看，可以看做Eclipse里面的一个个微服务工程或者Module。
注意,微服务、微服务架构、Spring Cloud是三种不同的概念，不要弄混淆。
三.微服务的优缺点
3.1 微服务的优点
1) 每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务。单机版的应用由于很多业务耦合在一起，修改代码时往往需要读懂一整块的业务功能，而微服务项目只需要了解其中一小块，由于项目足够小并且都是独立的，代码更容易理解，也更容易维
2) 开发简单，开发效率提高，精力集中，一个服务只做一件事。
3) 小团队也能单独开发，管理容易，管理成本降低。
4) 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段还是在部署阶段都是独立的，这样可以防止某个项目出问题了其他服务项目不会受到影响。
5) 微服务能使用不同语言开发。
6) 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，例如Jenkins,Hudson,bamboo。
7) 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
8) 微服务允许你利用融合最新技术。
9) 微服务只是业务逻辑代码，不会和HTML，CSS或其他界面组件混合。
10) 每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一的数据库。可以灵活搭配，连接公共库+连接独立库。
3.2 微服务的缺点
1) 开发人员需要处理分布式系统的复杂性。
2) 多服务运维难度，随着服务的增加，运维的压力也在增大。
3) 系统部署依赖，一个模块调不通有可能影响到其他模块的使用。
4) 服务间通信成本变高。
5) 数据的一致性问题。
6) 系统集成测试变复杂。
7) 性能监控变困难。
四.微服务的技术栈有哪些
微服务技术栈是多种技术的集合体。
-
-
服务的配置与管理:Netflix公司的Archaius、阿里的Diamond等
-
服务注册与发现:Eureka、Consul、Zookeeper等
-
服务调用:Rest、RPC、gRPC
-
服务熔断器:Hystrix、Envoy等
-
服务负载均衡:Ribbon、Nginx等
-
服务接口调用(客户端调用服务的简化工具):Feign等
-
消息队列:Kafka、RabbitMQ、ActiveMQ等
-
服务配置中心管理:SpringCloudConfig、Chef等
-
服务路由(API):Zuul等
-
服务监控:Zabbix、Nagios、Metrics、Spectator等
-
全链路追踪:Zipkin、Brave、Dapper等
-
服务部署:Docker、OpenStack、Kubernetes等
-
数据操作开发包:SpringCloud Stream(封装Redis、RabbitMQ、Kafka等发送接收消息)
-
事件消息总栈:Spring Cloud Bus
五.分布式框架的对比
-
-
整体解决方案和框架成熟度
-
社区热度
-
可维护性
-
学习曲线
-
-
当前IT公司用的微服务架构有哪些?
-
阿里Dubbo/HSF
-
京东JSF
-
新浪微博Motan
-
当当网DubboX
结论:SpringCloud满足几乎所有的微服务技术维度要求。
