码迷,mamicode.com
首页 > 其他好文 > 详细

《2016ThoughtWorks技术雷达峰会----微服务架构》

时间:2016-05-21 18:52:52      阅读:121      评论:0      收藏:0      [点我收藏+]

标签:

微服务架构   王键,ThoughtWorks, 首席咨询师

 

  首先微服务架构的定义,thoughtWorks在2012年3月的技术雷达中这样定义:

    “微服务架构是一种架构,它提倡将单一应用程序划分为一组小的服务,每个服务运行在其独立的进程中,服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体的业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。”

  从这个定义中可以知道,如何甄别一个一个架构是不是微服务架构,可以从2点来判断。

    一个是服务跑在单独的进程,另一个是可以独立部署。

  那么Microservices有什么优点,以至于它近年来如此的热?

  它有以下的四个优点:

    1、弹性架构

      什么叫弹性架构,可以设想以下场景。我们的系统是由一些小的服务构成,然后在通过容器这种非常灵活的基础设施,放入云的环境。假如现在双11.客户蜂拥而至,

    这时候系统会自动监控到系统的响应非常的紧张,系统会弹性的开启成千上万的服务。在高峰过去之后,系统会自动把这些服务取消,从开始到结束完全没有人在干扰,

    完全是自动化的。其实这种微服务架构结合Docker,结合云就为实现以上场景提供了一种可能。

    2、组件化

      传统的组件化是库和应用都运行在进程中,组件的任何局部变化都意味着应用的重新部署。但是通过服务来实现组件化,单个服务运行在单个进程中,某个服务的局部变动只影响该服务,而不影响整体的应用。并且因为要把应用拆分为多个微服务,对于跨进程间的调用,必须要定义清晰的职责和边界,这促进了组件的更清晰的边界。

    3、去中心化

       应用往往依赖于应用一开始对于技术的选择,比如你选择了.net,后几年的发展全是基于.net,因为这是一个大的应用。选择了Oracle,以后很难改变。但是微服务架构实现了一个耕细粒度的服务划分,可以在不同的服务里用不同的技术,不同的数据库,可以真正做到架构所追求的用最适合的技术解决

    4、快速响应

       所有以上的特点,其实都是为了快速响应需求的变化,响应市场的变化。快速响应意味着增加了竞争力

 

   但是微服务架构是带刺的玫瑰花,不是只有美丽。

    1、微服务架构会带来附加成本

    技术分享

    如图所示,系统复杂度低时,单一应用的生产效率更好。随着系统复杂度的增加,微服务架构的生产效率慢慢超过单一应用。这说明并不是任何时候应用微服务架构,就能取得较高的生产效率,因为它会带来附加的成本。

    2、很多团队在部署微服务的时候,要花费很长的时间。微服务的架构不该是更容易部署的么?

   根据技术雷达2014年7月版中提到的康威定律,“一个组织的设计成果,其结构往往对应于这个组织中的沟通结构”,它从正反两面支持了《敏捷宣言》的一个核心理念"个体与交互高于过程和工具"。

   要充分发挥微服务架构的能量,团队必须在构建、测试、集成以及管理方面进行良好的训练。所以,结论就是这些团队没有一个适合微服务架构的组织结构。逐渐改进你的团队和组织结构来促进你所渴望的技术架构。

 

今年的技术雷达对于微服务给出的关键词是:Microservice envy

   Fist law of Distributed Object Design :"don‘t distribute your objects",一方面很多应用微服务架构的团队,其实没有达到应用微服务架构的能力,个子不够高,还不足以达到微服务架构的要求。另一个方面好的架构是进化来的,不是设计来的,不要为了微服务而微服务。

  建议:单体应用优先,不要一开始就应用微服务,在演进中可以迁移到微服务。

    技术分享

    注:微服务架构只是一种架构风格,需要很多的技术来支持,技术雷达2014年列出了微服务很多相关的技术。

《2016ThoughtWorks技术雷达峰会----微服务架构》

标签:

原文地址:http://www.cnblogs.com/grass-stars/p/5512604.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!