1、什么是微服务?
微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。微服务架构模式(Microservices Architecture Pattern)的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务,每个服务都可以很容易做局部修改。微服务架构带来可独立部署、高扩展与伸缩、自由选择开发语言、高效利用资源、故障隔离等优点,同时也因为服务多带来分布式事务、服务之间通信、监控、部署等新的问题。
2、为什么要用微服务?
整体式架构应用图(以华为软件开发云为假设-其实他应该属于微服务架构):
![](http://upload-images.jianshu.io/upload_images/5609636-609fccce642cb999.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
整体式架构的不足
使用传统的整体式架构(Monolithic Architecture)应用开发系统易于开发,易于调试,也易于部署。在早期这类应用运行的很好,不幸的是,这种简单方法却有很大的局限性。
1)一个简单的应用会随着时间推移逐渐变大。在每次的sprint中,开发团队都会面对新story,新的task,然后开发许多新代码。几年后,这个小而简单的应用会逐渐变大。
2)一旦你的应用变成一个又大又复杂的怪物,开发团队肯定很痛苦。由于应用太大太复杂,以至于任何单个开发者都不可能搞懂它。因此,修正bug和正确的添加新功能变的非常困难,并且很耗时。
3)整体式架构应用也会降低开发速度。应用越大,启动时间会越长。如果开发者需要经常重启应用,那么大部分时间就要在等待中渡过,生产效率受到极大影响。
4)复杂而巨大的整体式架构应用不利于持续性开发。今天,SaaS应用常态就是每天会改变很多次,而这对于整体式架构模式非常困难。
5)整体式架构应用另外一个问题是可靠性。因为所有模块都运行在一个进程中,任何一个模块中的一个bug,比如内存泄露,将会有可能弄垮整个进程。
6)整体式架构应用使得采用新架构和语言非常困难。比如你的代码使用A框架写的,如果想改成B框架,无论是时间还是成本都是非常昂贵的。因此,这是一个无法逾越的鸿沟。
微服务架构图(以华为软件开发云为例):
![](http://upload-images.jianshu.io/upload_images/5609636-f86d3e5f52e2a578.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
微服务架构的好处
第一,通过分解巨大单体式应用为多个服务的方法解决了复杂性问题。在功能不变的情况下,应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案,由此,单个服务很容易开发、理解和维护。
第二,这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术,提供API服务。这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术,他们可以选择现在的技术。甚至于,因为服务都是相对简单,即使用现在技术重写以前代码也不是很困难的事情。
第三,微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。团队可以采用AB测试,快速的部署变化。微服务架构模式使得持续化部署成为可能。
最后,微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的云服务。比如,你可以为计算密集型服务选择高配置的云主机,而在为存储密集型的服务选择高带宽高存储的云主机。
3、微服务,真的适合你么?
![](http://upload-images.jianshu.io/upload_images/5609636-f816496fc88001cf.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
提到微服务架构时,我们常常会与整体式架构进行比较,整体式架构存在如下缺点:代码维护难度大,臃肿的部署,局限的弹性与扩展能力,阻碍团队与技术革新等等;微服务架构存在如下优点:代码维护简化,可独立部署,高扩展与伸缩,自由选择开发语言等优点。那么整体式架构真的这么差吗?显然不是。
在复杂度较小时采用整体式架构的生产率更高,复杂度到了一定规模时,单体应用的生产率开始急剧下降,这时对其进行微服务化的拆分才是合理的。所以说脱离业务场景,空谈架构绝对是耍流氓。
![](http://upload-images.jianshu.io/upload_images/5609636-9b741d2b8cb63b25.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
再牛逼的架构设计,如果无法在业务场景中落地实施,也只是空谈。因此架构需要服务于业务,针对不同的业务场景架构设计也会不同,架构设计不必追求高大上,只要能满足业务发展需求,便是好架构。
此外,好的架构不完全是设计出来的,随着业务量、请求量的增长,好的架构是演化而来的。微服务架构之所以得到广泛认可,源于对于业务多变性的不可预测,微服务架构能够不断的自演化,进而快速适应业务变化。此外,微服务也有他的不足之处:
第一,微服务应用是分布式系统,由此会带来固有的复杂性。
第二,分区的数据库架构在微服务架构应用中,需要更新不同服务所使用的不同的数据库,这对开发者提出了更高的要求和挑战。
第三,测试一个基于微服务架构的应用也是很复杂的任务。
第四,微服务架构模式应用的改变将会波及多个服务。
第五,部署一个微服务应用也很复杂。一个微服务应用一般由大批服务构成。成功部署一个微服务应用需要开发者有足够的控制部署方法,并高度自动化。
鉴于上述原因,如果公司的长期业务规划不需要微服务架构或者公司的实际情况不具备实施微服务一些基本的条件,不建议各位盲目迈向微服务这一新兴架构领域。如果准备早点进行技术积累,也可以从试点开始,逐步在团队中推行微服务架构。
4、微服务,如果真的适合你,应该怎么做?
1)买书学习。
2)上网查资料学习。
3)用华为软件开发云,让华为专家指导你。
![](http://upload-images.jianshu.io/upload_images/5609636-00b3a41676a3fb97.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)