[包子分享] 构架模式: Microservices Architecture

http://baozitraining.org

微服务构架是近年来比较流行的服务端应用构架，由其非常好的可伸缩性，稳定性以及灵活的协同开发模式而著称于世。越来越多的公司都或多或少地开始采用微服构架，比如Netflix，Amazon， 等等。其实为服务并非什么新框架，它本质上是非常老的SOA 构架的一种实现方式。在本文中，包子将为大家简单讲解一下为服务的一些基本概念及优势，然后再分享一篇文章来阐述它的一些pitfalls， 希望同学们看完能有所收获。

什么是微服务

设想你正在开发一个电子商务应用，需要有商品浏览，订单管理，库存管理以及发货等功能（想象下亚马逊）。如果只是简单地按照传统的分成层构架来经行，比如加入：

• 表示层处理用户请求；
• 业务逻辑层处理不同功能模块的业务；
• 数据库层处理所有业务逻辑的数据请求。

这个应用的每一层都会变得十分复杂，而且我们必须另外想办法来解决其可伸缩性的问题。

我们在对整个网络应用经行开发维护的时候，不同的功能模块都可能会在不同时期经行升级。如何能够在不同模块上使用不同的技术手段，并且在不间断整体服务的基础上经行升级集成成了一个挑战。

对于这个应用的开发和维护，必然会有一个很大的团队来经行，那么如何尽量使所有成员最小化其所须要关心的领域，并且能很方便地对团队经行管理也是一个很大的challange。

于是在微服务的构架下面，你这个电子商务应用经行纵向切分：每一个功能模块，比如订单管理，库存管理等包装成一个独立的服务，有着自己独立的接口和负载均衡模块，运行在自己专门的一个服务器(集群）上，以及使用专门的数据库等。当然，为了减少物理服务器开销，往往这些服务是运行在虚拟机或者是 container 上面。这样，公司的团队也被划分成了多个小团队(conways law),分别接管一个独立的服务--从开发测试到部署维护。

微服务的优势

这种微服务的优势非常明显，

• 首先，它天生的分布式构架自然地解决了程序扩展性和稳定性的问题。每个服务可以按需地在不同的服务器上运行多个实例经行负载平衡和容错，而且它把错误隔离的很好，每个模块的错误不会影响到其他模块上；
• 其次，由于每个服务都非常小，于是逻辑十分好理解。新的开发人员可以很快上手，没有太多负担，并且也方便内部的重新构架（对外部是透明的）；
• 然后每一个服务都可以经行随时的不间断地升级，而不用有破坏整个应用的烦恼，只要接口保持一致；
• 最后，由于每个服务都是独立的，所以完全可以按需要使用不同的技术构架，从而达到最大化效益。

微服务不是免费的午餐

I am currently involved in architecting a system based around Microservices, and whilst the individual services are very simple, a lot of complexity exists at a higher level level in terms of managing these services and orchestrating business processes throughout them. Microservices one of these ideas that are nice in practice, but all manner of complexity comes out when it meets reality. For this reason, I wanted to write this article to capture some of these and redress the balance. Significant Operations Overhead A Microservices architecture brings a lot of operations overhead. Where a monolithic application might have been deployed to a small application server cluster, you now have tens of separate services to build, test, deploy and run, potentially in polyglot languages and environments. All of these services potentially need clustering for failover and resilience, turning your single monolithic system into, say, 20 services consisting of 40-60 processes after we've added resilience. Throw in load balancers and messaging layers for plumbing between the services and the estate starts to become pretty large when compared to that single monolithic application that delivered the equivalent business functionality! Productionising all of this needs high quality monitoring and operations infrastructure. Keeping an application server running can be a full time job, but we now have to ensure that tens or even hundreds of processes stay up, don't run out of disk space, don't deadlock, stay performant. It's a daunting task. Physically shipping this plethora of Microservices through your pipeline and into production also needs a very high degree of robust and release and deployment automation. Currently, there is not much in terms of frameworks and open source tooling to support this from an operational perspective. It's likely therefore that a team rolling out Microservices will need to make significant investment in custom scripting or development to manage these processes before they write a line of code that delivers business value. Operations is the most obvious and commonly held objection towards the model, though it is too easily brushed aside by proponents of this architecture.