SpringCloud--微服务简介

1 什么是微服务？

      微服务的概念最早是在2014年由MartinFowler和JamesLewis共同提出,他们定义了微服务是由单一应用程序构成的小服务,拥有自己的进程与轻量化处理,服务依业务功能设计,以全自动的方式部署与其他服务使用HTTPAPI通讯.同时,服务会使用最小规模的集中管理(例如Docker)技术,服务可以用不同的编程语言与数据库等.

• 简单举例：看军事新闻的同学应该都知道,一艘航空母舰作战能力虽然很强,但是弱点太明显,就是防御能力太差,单艘的航空母舰很少单独行动,通常航空母舰战斗群才是主要军事力量,你可以把单艘航母理解为的单体应用(防御差,机动性不好),把航母战斗群(调度复杂,维护费用高)理解为微服务.

2 为什么使用微服务？

        2.1 单体应用特点

      大部分的开发者经历和开发过单体应用,无论是传统的Servlet+JSP,还是SSM,还是现在的SpringBoot,它们都是单体应用,那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题,导致我们要抛弃单体应用转向微服务架构？

主要原因如下：

1. 部署成本高(无论是修改1行代码,还是10行代码,都要全量替换).
2. 改动影响大,风险高(不论代码改动多小,成本都相同).因为成本高,风险高,所以导致部署频率低(无法快速交付客户需求).无法满足快速扩容,弹性伸缩,无法适应云环境特性等问题.

        2.2微服务特点

      微服务架构的特点:针对特定服务发布,影响小,风险小,成本低；频繁发布版本,快速交付需求；低成本扩容,弹性伸缩,适应云环境.我们知道一个朴素的理念,没有任何事物是完美的,任何东西都有两面性,有得必有失,那么在选择微服务在解决了快速响应和弹性伸缩的问题同时,它又给我们带来了什么问题？
    简单总结如下：

1. 分布式系统的复杂性

2. 部署,测试和监控的成本问题

3. 分布式事务和CAP的相关问题

4. 系统应用由原来的单体变成几十到几百个不同的工程,会所产生例如包括服务间的依赖,服务如何拆封,内部接口规范,数据传递等等问题,尤其是服务拆分,需要团队熟悉业务流程,懂得取舍,要保证拆分的粒度服务既符合“高内聚,低耦合”的基本原则,还要兼顾业务的发展以及公司的愿景,要还要说服团队成员为之努力,并且积极投入,在多方中间取得平衡.

      对于分布式系统,部署,测试和监控都需要大量的中间件来支撑,而且中间件本身也要维护,原先单体应用很简单的事务问题,转到分布式环境就变得很复杂,分布式事务是采用简单的重试+补偿机制,还是采用二阶段提交协议等强一致性方法来解决,就要取决对业务场景的熟悉加上反复的权衡了,相同问题还包括对CAP模型的权衡,总之微服务对团队整体的技术栈水平整体要求更高.

3 应用架构变迁图