springcloud微服务系列课程——1

为什么需要将单一应用拆成微服务——微服务优点

• 根据业务的不同将服务拆分成一个一个的应用，实现完全的解耦
• 每个服务都很小，多个服务之间可以并行开发互不影响
• 微服务能使用不同的语言开发（不同语言之间可以通过sidecar进行相互调用）
• 每个服务都可以有自己的数据库，也可以用公共的

微服务缺点

• 机器内存消耗大，每个服务单独部署，都要启动一个jvm
• 随着服务数量增多，难以维护
• 服务间通信的成本变高了
• 因为是分布式部署，所以问题追踪难
• 运维压力增大，当服务比较多的时候需要配合自动化部署工具

微服务技术栈

微服务条数	落地技术
服务开发	spring、springmvc、springboot
服务注册发现	Eureka、zookeeper
服务调用	Rest 、Rpc 、gRpc
负载均衡	Ribbon、nginx
服务配置与管理	netfinx公司的archaius 、阿里巴巴的damond
服务熔断	hystrix
消息队列	kafka、各种mq
服务路由（API网关）	Zuul
服务接口调用	Feign
全链路追踪	zipKin  brave等
时间消息总线	springcloud bus
服务部署	Docker   k8s等

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

• 整体架构微服务解决方案还是比较全，成熟
• 社区活跃度也很高
• 学习成本也不是很大，如果单纯想要会用那学几个注解就行
• 可维护性比较好

从CAP原则对比 dubbo和zookeeper

CAP理论告诉我们，一个分布式系统不可能同时满足以下三种

• 一致性（C:Consistency）
• 可用性（A:Available）
• 分区容错性（P:Partition Tolerance）

又由于P，分区容错性是必须的，所以一般都会从AP和CP中去做选择

一致性（C:Consistency）

在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。 

可用性（A:Available）

可用性是指系统提供的服务必须一直处于可用的状态，都是可以一直提供服务的。

分区容错性（P:Partition Tolerance）

分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络等）中，由于一些特殊的原因导致这些子网络之间出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。
 

ZooKeeper保证的是CP

•  zk不能保证每次服务请求的可用性，也就是说在特定情况下zk会丢掉一部分客户端请求，比如：

进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性。