微服务架构
微服务的由来
由Martin Fowler和James Lewis在2014年共同提出
微服务架构风格是一种使用一小套小服务开发单个应用的方式，每个服务运行在自己的进程中，并且使用轻量机制通信（HTTP API）,这些服务基于业务能力构建，并通过自动化部署机制独立部署（可以使用不用的编程语言，以及不同的数据存储机制来实现）
微服务是什么
微服务的核心就是将传统的一站式应用，跟还有业余拆成一个个服务，彻底的去耦合，每一个微服务提供单个业务的功能服务（一个服务只做一件事，把事情交给专业的机制去做）
从技术的角度来看微服务就是一种小而独立的处理过程，类似于进程概念，能够自己单独启动或者销毁，拥有自己独立的数据库
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力
尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等等
微服务架构的思想是从与整体应用对比而产生的
微服务架构的优缺点
优点
- 每个服务足够内聚，足够小，代码容器容易理解，这样能聚焦一个指定的业务功能和业务需求
- 开发简单，开发效率高，一个服务可能就只是专一只做一件事
- 微服务能被小团队单独开发
- 微服务是松耦合的，是具有功能意义的服务，无论在开发阶段和部署阶段都是独立的
- 技术异构 - 微服务可以使用不同的语言开发。在一个大型系统中，不同的功能具有不同的特点，并且不同的团队可能具备不同的技术能力。因为微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发，同时，在应用新技术时，可以仅针对一个微服务进行快速改造，而不会影响系统中的其它微服务，有利于系统的演进
- 微服务之间可以使用轻量机制（HTTP）来通信
- 易于和第三方集成，微服务允许集成灵活的自动部署，通过持续的集成工具(jenkis,Bamboo....)
- 微服务运行使用融合新技术
- 微服务只是业务逻辑代码，不会和HTML、CSS或其他界面组件混合
- 每个服务之间都有独立的存储方式和功能，可以有自己的数据库，也可以统一数据库
- 可扩展 - 应对系统业务增长的方法通常采用横向（Scale out）或纵向（Scale up）的方向进行扩展。分布式系统中通常要采用Scale out的方式进行扩展。因为不同的功能会面对不同的负荷变化，因此采用微服务的系统相对单块系统具备更好的可扩展性
- 灵活组合 - 在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的（比如在示例中，如果我们要新增一个Booking Service，在预订时可以直接重用Account Service和Inventory Service检查用户权限和库存情况。）
- ......
缺点
- 开发人员要处理分布式系统的复杂性,微服务间通过REST、RPC等形式交互，相对于Monolithic模式下的API形式，需要考虑被调用方故障、过载、消息丢失等各种异常情况，代码逻辑更加复杂
- 多服务运维难度，随着服务增加，运维压力也在增大。在采用微服务架构时，系统由多个独立运行的微服务构成，需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维系统
- 系统部署的依赖
- 服务之间的通信成本,相对于Monolithic架构，微服务的间通过REST、RPC等形式进行交互，通信的时延会受到较大的影响
- 数据的一致性(对于微服务间的事务性操作，因为不同的微服务采用了不同的数据库，将无法利用数据库本身的事务机制保证一致性，需要引入二阶段提交等技术)
- 系统集成测试
- 性能监控
- ......
微服务技术栈
微服务技术栈=多种技术的集合
常见的分布式微服务架构有
- 服务治理
- 服务注册
- 服务调用
- 服务负载均衡
- 服务监控
- .....
SrpingCloud
SrpingCloud概念
Srping Cloud是一个微服务框架，相比Dubbo（阿里云）的RPC框架，Srping Cloud提供了一全套的分布式系统解决方案
Srping Cloud为微服务框架开发涉及到的配置管理、服务治理、熔断机制、智能路由、微代理、控制总线、一致性Token、全局一致性锁、leader选举、分布式seesion、集群状态管理、....等操作提供了一种简单的开发方式
Srping Cloud对微服务基础框架NetFlix(全球十大视频网站的唯一收费的)的多个开源组件进行了封装，同是又实现了和云端平台以及SpringBoot开发框架的集成
