浅谈微服务架构
一、什么是微服务架构
微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。
概念:把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务,它可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等级协议。
定义:围绕业务领域组件来创建应用,这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能,使产品交付变得更加简单。
本质:用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
二、为什么需要微服务架构
“微服务”架构是近些年软件应用领域非常热门的概念。让我们先来看看传统IT架构面临的一些问题:
1、使用传统的整体式架构(Monolithic Architecture)应用开发系统,如CRM、ERP等大型应用,随着新需求的不断增加,企业更新和修复大型整体式应用变得越来越困难;
2、随着移动互联网的发展,企业被迫将其应用迁移至现代化UI界面架构以便能兼容移动设备,这要求企业能实现应用功能的快速上线;
3、许多企业在SOA投资中得到的回报有限,SOA可以通过标准化服务接口实现能力的重用,但对于快速变化的需求,受到整体式应用的限制,有时候显得力不从心;
4、随着应用云化的日益普及,生于云端的应用具有与传统IT不同的技术基因和开发运维模式。
此外,从技术方面看,云计算及互联网公司大量开源轻量级技术不停涌现并日渐成熟:
1、互联网/内联网/网络更加成熟;
2、轻量级运行时技术的出现(node.js, WAS Liberty【轻量级、模块化应用服务器】等);
3、新的轻量级协议(RESTful API接口, 轻量级消息机制);
4、简化的基础设施:操作系统虚拟化(hypervisors), 容器化(e.g. Docker), 基础设施即服务 (IaaS), 工作负载虚拟化(Kubernetes,Spark…)等;
5、服务平台化(PaaS): 云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务;
6、新的可替代数据持久化模型:如NoSQL, MapReduce, BASE, CQRS等;
7、标准化代码管理:如Github等。
三、传统开发模式和微服务的区别
基于单应用程序的设计:
先来看看传统的web开发方式,通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的,这种方式一般被称为Monolithic(单体式开发)。
所有的功能打包在一个 WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了 DO/DAO,Service,UI等所有逻辑。

优点:
①开发简单,集中式管理
②基本不会重复开发
③功能都在本地,没有分布式的管理和调用消耗
缺点:
1、效率低:开发都在同一个项目改代码,相互等待,冲突不断
2、维护难:代码功功能耦合在一起,新人不知道何从下手
3、不灵活:构建时间长,任何小修改都要重构整个项目,耗时
4、稳定性差:一个微小的问题,都可能导致整个应用挂掉
5、扩展性不够:无法满足高并发下的业务需求
基于微服务架构的设计:
目的:有效的拆分应用,实现敏捷开发和部署

优点:
1、每个服务都比较简单,只关注于一个业务功能。
2、微服务架构方式是松耦合的,可以提供更高的灵活性。
3、微服务可通过最佳及最合适的不同的编程语言与工具进行开发,能够做到有的放矢地解决针对性问题。
4、每个微服务可由不同团队独立开发,互不影响,加快推出市场的速度。
5、微服务架构是持续交付(CD)的巨大推动力,允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。
缺点:
1、运维开销及成本增加:整体应用可能只需部署至一小片应用服务区集群,而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务,并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成,可能需要40~60个进程。
2、隐式接口及接口匹配问题:把系统分为多个协作组件后会产生新的接口,这意味着简单的交叉变化可能需要改变许多组件,并需协调一起发布。在实际环境中,一个新品发布可能被迫同时发布大量服务,由于集成点的大量增加,微服务架构会有更高的发布风险。
3、代码重复:某些底层功能需要被多个服务所用,为了避免将“同步耦合引入到系统中”,有时需要向不同服务添加一些代码,这就会导致代码重复。
4、分布式系统的复杂性:作为一种分布式系统,微服务引入了复杂性和其他若干问题,例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等,开发人员需要考虑以上的分布式系统问题。
5、异步机制:微服务往往使用异步编程、消息与并行机制,如果应用存在跨微服务的事务性处理,其实现机制会变得复杂化。

额。好像走错片场了............................
接下来,就看看具体怎么用spring-cloud的相关组件来搭建自己的微服务架构应用。
1、服务注册与发现
3、服务网关
就这些吧,这些都仅仅是个小例子,当应用到自己的应用服务中还有很长的路很多的坑要踩。