微服务构架是近年来比较流行的服务端应用构架，由其非常好的可伸缩性，稳定性以及灵活的协同开发模式而著称于世。越来越多的公司都或多或少地开始采用微服构架，比如Netflix，Amazon， 等等。其实为服务并非什么新框架，它本质上是非常老的SOA 构架的一种实现方式。在本文中，包子将为大家简单讲解一下为服务的一些基本概念及优势，然后再分享一篇文章来阐述它的一些pitfalls， 希望同学们看完能有所收获。
于是在微服务的构架下面，你这个电子商务应用经行纵向切分：每一个功能模块，比如订单管理，库存管理等包装成一个独立的服务，有着自己独立的接口和负载均衡模块，运行在自己专门的一个服务器(集群）上，以及使用专门的数据库等。当然，为了减少物理服务器开销，往往这些服务是运行在虚拟机或者是 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.
原文发布于微信公众号 - 包子铺里聊IT（baozitraining）