初探微服务架构模式

什么是微服务架构？

　　我所理解的微服务架构，其实还是SOA架构思想的一种实现。不同的是，微服务并没有ESB这种集合层组件。微服务架构中的每个小服务围绕业务能力来构建，提供API供外部访问。它们独立运行在自己的进程中，相互之间不造成干扰。每个小服务可以使用不同的编程语言、不同的数据存储技术来构建，决定使用何种技术的关键在于业务需求和项目管理规范。另外，微服务架构还需要自动化运维来支撑，否则随着业务系统复杂度的不断增加，微服务架构的开发、运维成本也将不断增加。

微服务架构有哪些优缺点？

　　要了解微服务架构有哪些优缺点，我们可以想想，是什么原因，导致我们想去使用微服务架构。无非就是，原有架构开发、测试、维护的成本越来越高了，甚至由于原有架构的一些缺陷，导致一系列工作无法正常开展。

　　比如我们常用的单体架构，随着业务的扩展，代码量的增多，即使我们在设计初期就把架构设计得比较完善，每个业务模块都基于高内聚低耦合的标准来进行设计，但还是无法避免后期开发越来越吃力，代码重复率高，开发团队之间的相互协作困难，开发时间难以把控。对测试、运维来说，对某一功能模块进行了修改优化后，都需要对整个系统重新测试，部署。而且，在传统开发过程中，我们往往是某个人或者某些人，专门负责独立模块的功能开发，一旦原负责人离开了，这些功能模块就变得难以把控起来。里面的一些模块间调用，公共库使用，基本上只有原负责人才能说得清楚，久而久之，整个架构就会渐渐出现问题。

下面结论转载于 ：http://blog.csdn.net/sunhuiliang85/article/details/52976323

（1）优点

1.      每个微服务相对较小

 

　　l  开发者易于理解

 

　　l  IDE处理效率快，利于提高劳动生产率

 

　　l  Web容器压力小，容器启动速度快，易于提供劳动生产率和生产环境部署速度

 

2.      每个微服务都可以独立部署，简化了部署新服务版本的流程

 

3.      易于规模化开发，多个开发团队可以并行开发，每个团队负责一项服务

 

4.      改善故障隔离。一个服务宕机不会影响其他的服务

 

5.      每个服务可以独立的进行开发和部署

 

6.      无需长期使用同一套技术栈

 

（2）缺点

 

1.开发者需要应对创建分布式系统所产生的额外的复杂因素

 

　　l  目前的IDE主要面对的是单体工程程序，无法显示支持分布式应用的开发

 

　　l  测试工作更加困难

 

　　l  需要采用服务间的通讯机制

 

　　l  很难在不采用分布式事务的情况下跨服务实现功能

 

　　l  跨服务实现要求功能要求团队之间的紧密协作

 

2.部署复杂

 

3.内存占用量更高

 

下面结论转载于 ： http://www.cnblogs.com/zgynhqf/p/5679028.html?utm_source=tuicool&utm_medium=referral

微服务的一些优势是显而易见的：

1. 服务简单，只关注一个业务功能 
   在James看来，传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性，其服务端应用就像是一块铁板，笨重且不可拆分，系统中任何程序的改变都需要整个应用重新构建和部署新版本。在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。 
   而微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务即可。
2. 每个微服务可由不同团队开发 
   传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，不同的服务可以采用不同的技术来实现，一个团队中应该包含开发所需的所有技能，比如用户体验、数据库、项目管理。
3. 微服务是松散耦合的 
   微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每个服务都会处理相应的业务，所有的业务逻辑应该尽量在服务内部处理，且服务间的通信尽可能的轻量化，比如使用Restful的方式。
4. 可用不同的编程语言与工具开发 
   传统的软件开发中经常会使用同一个技术平台来解决所有的问题，而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性，我们可以使用Node.js来开发一个简单的报表页面，使用C++来编写一个实时聊天组件。

微服务架构的引入为多样化持久保存数据提供可能，持久层可以使用传统关系数据库和NoSQL。不同于传统的应用，微服务架构中，我们可以为每个服务选择一个新的适合业务逻辑的数据库系统，比如MongoDB、PostgreSQL。这样做的好处是显而易见的，首先我们可以根据业务类型（读多还是写多等）来决定使用哪种类型的数据库，其次这样可以减小单个数据库的负载。 
James的文章在社区引起了广泛的讨论，Contino公司的CTO Benjamin Wootton撰文表示微服务并没有想象中的那么好，并建议开发者在选用此架构时一定要慎重。Benjamin认为微服务架构时可能会面临下面一些挑战：

1. 运维开销 
   更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。
2. DevOps要求 
   使用微服务架构后，开发团队需要保证一个Tomcat集群可用，保证一个数据库可用，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少。
3. 隐式接口 
   服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。
4. 重复劳动 
   在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。
5. 分布式系统的复杂性 
   微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。
6. 事务、异步、测试面临挑战 
   跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。