html
1) Martin Fowler论文对微服务的阐述(中文版)ios
2) 对单一应用进行拆分spring
3) 每个独立的应用都有一个独立的进程数据库
4) 拥有本身独立的数据库springboot
5) 微服务化的核心就是讲传统的一站式应用,根据业务拆分红一个一个的服务,完全地去耦合,每个微服务提供单个业务功能的服务,一个服务处理一件事,从技术角度就是一种小而独立的处理过程,相似进程的概念,可以自行单独启动或销毁,拥有本身的数据库。架构
二.微服务与微服务架构app
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知足几乎全部的微服务技术维度要求。