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

微服务架构   王键，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年列出了微服务很多相关的技术。