微服务
就目前而言微服务，业界没有统一标准的定义
微服务架构是一种架构模式，或者是一种架构风格他提倡单一应用程序划分一组小服务，每个服务运行在自己独立的进程内，服务之间，互相协调，互相配置，为用户提倡最终的价值，体现最终价值，服务之间采用轻量级的通信机制互相沟通，每个服务围绕具体的业务构建，并且能够被独立的部署在生产环境中，另外，尽量避免统一的，集中式管理的服务管理机制，对具体的一个服务而言，根据上下文，选择合适的语言，工具，对齐构建，可以有一个非常轻量的集中式管理来协调业务，可以使用不同的语言编写，也可以用不同的数据储存
我们从技术维度理解一下
就是微服务的作用就是将传统的一个项目解决业务（一站式应用）根据业务拆分成一个一个的服务，去彻底的去耦合，每个微服务提供单个业务的功能服务，一个服务做一个事情，从技术角度来说就是一个小而独立的处理过程，类的进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库
微服务与微服务架构
微服务
强调的是服务的大小 ，他关注的是一个点，是具体解决某一个问题提供落地对服务的应用，就是idea中一个个微服务的工程或者moudel
idea工具里面使用maven建立的一个个独立的小moudle，他具体是使用springboot开发的一个个小模块，专业的事情交给专业的模版来做，一个模块做着一件事情
强调的是一个个的个体，每个个体完成一个具体的任务或者功能！
微服务架构
一钟新的架构形式，Martin Fowler
2014推出
微服务架构是一种架构模式，或者是一种架构风格他提倡单一应用程序划分一组小服务，每个服务运行在自己独立的进程内，服务之间，互相协调，互相配置，为用户提倡最终的价值，体现最终价值，服务之间采用轻量级的通信机制互相沟通，每个服务围绕具体的业务构建，并且能够被独立的部署在生产环境中，另外，尽量避免统一的，集中式管理的服务管理机制，对具体的一个服务而言，根据上下文，选择合适的语言，工具，对齐构建，可以有一个非常轻量的集中式管理来协调业务，可以使用不同的语言编写，也可以用不同的数据储存
微服务的有缺点
优点
单一职责原则
每个服务足够内聚，足够小，代码容易理解，这个能聚焦一个指定的业务功能和业务需求
开发简单，开发效率提高，一个服务可能就是转义的只干一件事情
微服务能够被小团队单独开发，这个小团队是2~5的开发人员组成
微服务是松耦合的，是具有功能意义的服务，无论是在开发阶段或者部署阶段都是独立的
微服务能使用不同的预言开发
易于是第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins，hudson，bamboo
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更加关注自己的工作成果。无需通过合作才能体现价值
微服务允许你利用融合最新技术
微服务只是业务逻辑的代码，不会喝html，css或其他的界面混合
每个微服务都有自己的储存能力，可以有自己的数据库，也可以有统一数据库
缺点：
开发人员要处理分布式系统的复杂性
多服务运维难度，随着服务的增加，运维压力也在增大
系统部署依赖
服务间通信成本
数据一致性
系统集成测试
性能监控
微服务技术栈
为什么我们要选择SpringCloud作为微服务架构呢
1、选型依据
- 整体解决方案和框架成熟度
- 社区热度
- 可维护性
- 学习曲线
2、当前各大公司微服务架构是那些
- 阿里：dubbo+hfs
- 京东：jsf
- 新浪：Motan
- 当当： bubbox
springcloud入门概述
springcloud是什么？
springcloud基于springboot提供了一套微服务解决方案，包括服务注册，发现，配置中心，全链路监控
服务网管，负载均衡，熔断器等组件，除了基于netflix的开源组件做高度抽象封装之外，还有一些选型中立得1开源组件。
springcloud利用springboot的开发便利性，巧妙的简化了分布式系统基础设施额开发，springcloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等，他们都可以用springboot的开发风格做到一键启动部署
springboot并没有重复造轮子，他只是将目前各家公司开发的比较成熟经得起实际考研的 服务框架组合起来，通过springboot风格进行封装，屏蔽掉了复杂的配置，和实现原理，最终给开发者留出一套简单易懂，易部署，和易维护的分布式系统开发工具包
springcloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶
springboot和springcloud的关系
springboot专注于快速方便的开发单个个体微服务
springcloud是关注全局微服务协调治框架，他将springboot开发的一个个单体微服务，整合并管理起来，为各个微服务之间提供了配置管理，服务发现，断路器，路由，事件总线全局锁，决策竞选，分布式会话等等集成服务
springboot可以离开springcloud独立使用，开发项目，但是springcloud离不开springboot，属于依赖关系
springboot专注于快速方便的开发单个个体微服务，springcloud关注全局的服务治理框架
Dubbo和springcloud技术选型
分布式+服务治理Dubbo
目前成熟的互联网架构：应用服务化拆分+消息中间件
Dubbo和springcloud对比
dubbo应为停更了之后，社区并不活跃，垂死状态，未来未知
springcloud的社区十分活跃，正值壮年，
对比图：
最大区别：springcloud抛弃了Dubbo的rpc通信，采用基于http的rest方式
严格来说，两种方式各有优劣，从一定程度上，后者牺牲了服务调用的性能，但是也比避免了原生rpc带来的问题，rest相比rpc更加的灵活，服务提供方和调用方的依赖只靠一个七月，不存在在吗级别的强依赖，这就是强调快速烟花的微服务环境下，显得更加合适
品牌机和组装机的区别
springcloud（品牌机）：
很明显的一点就是，springcloud的功能比dubbo强大的太多，覆盖面更广，而且作为spring的明星项目，他也能够和其他的spring项目完美融合。
dubbo（组装机）：
使用dubbo构建微服务架构就像组装电脑，各环节，我们的选择自由度非常高，但是最终结果可能是就是一个内存条不点亮了，总是不让人那么放心，但是如果是一个高手，那这些都不是问题，
springcloud就像品牌机，在spring source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础足够了解，
社区支持和更新力度
最重要的是，dubbo停止了5年狗熊，虽然17年重启了，对于技术发展的需求，更需要爱发展着自行拓展升级，比如dubbox，对于这很多想要采纳微服务的中小软件组织，显然是不太合适的，中小公司没有那么强大的技术去修改dubbo的源码+周边的一整套解决方案。并不是每个公司都有阿里的大牛+真实线上生产环境测试过
总结
曾风靡国内的rpc框架Dubbo在重启维护后，让很多用户为之雀跃，但是同时也要有质疑的声音，发展迅速的时代，dubbo能否跟上?dubbo和springcloud的差异 ？是否会有相关的举措保证dubbo的后续更新频率
dubbo是一个专注rpc框架，springcloud的目标是微服务架构下的一站式解决方案
设计模式+微服务拆分思想：不一定善于表达的技术人才，你可以领导他，软实力是职场关键的一点，你可能技术没有人才好，但是你的设计思维，架构理解和表达能力让你可以成为只会技术人才的团队leader，
