七牛技术总监肖勤：微服务架构实践经验分享（摘抄）

原文网址 http://www.csdn.net/article/2015-08-07/2825412?foxhandler=RssReadRenderProcessHandler
肖勤首先简单介绍了微服务（Microservices）的内涵及优势，他表示，微服务架构的本质，是用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

微服务架构将服务拆分，分别采用相对独立的服务对各方面进行管理，彼此之间使用统一的接口来进行交流，架构变得复杂，优势也很明显：

复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。
<
4000
strong>技术选型灵活[/b]：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。
容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
         -------------------------------------------------------------------------------------------------------------------------------------------------------------------------

1.对于做好事情、维护好产品而言，微服务架构不是唯一的方向，但是它是一个比较靠谱的思路和方向。如果你把所有的东西放到一起，都自己来做，势必需要很多资源来维护它，如果拆分开，把一些基础服务部件交给专业做基础服务的人来做，成本通常会比自己做的要低得多。要利用好云计算资源，服务就是拆分越细越好。

对于创业团队来说，我个人认为，不必刻意去追求微服务。尤其在创业初期，首先需要把产品做出来，等到方向得到验证，服务越来越复杂，团队越来越庞大之后，再适当放慢脚步，考虑团队架构、产品架构的调整，如何能够用同样的资源做更多的事情。

2.首先，企业要有一致的想法，认同微服务架构带来的好处。

其次，这个过程要循序渐进，不能操之过急。不一定是方向的问题，而是执行过程的问题。先挑选边缘的服务、基础性的服务、可替代性强的服务，它们用基础云服务替代，而不是自己维护，或者把多项业务的共通部分拆出来，用少数人来维护，看看这样做是否真的有好处，切实解决问题，节约资源，在有好处驱动的情况下，再决定推进架构变革。如果架构比较特殊，不适合微服务，通过边缘服务的尝试，可以及时发现问题。

3.

服务的分拆肯定会让结构更加复杂，但微服务在理念描述上已经意识到，从服务架构着眼，设计上考虑了部署的问题，运营在架构中的优先级也是排在第一位的，而以往在设计模式、软件架构基本不会考虑到部署、运营的问题。所以，如果要支持微服务架构，必须有一套行之有效的运营、部署的工具和方式，这也是容器相关技术和容器云现在备受关注的一个原因。

依赖的问题，包括一部分的复杂性问题，取决于拆分时候边界和接口的定义、数据联通的方式，设计得是不是足够合理，服务提供者是不是清楚需求的方式，服务调用者是不是理解接口的意图，也就是说团队针对每个服务的沟通，对事情的定位，对接口的抽象，是不是有一个同样的认知水平，达成一个共识。只要保证接口稳定、合理，实现不管怎么变化，对整合架构就不会有负面影响。服务的局部修改反而可以更快速，因为不会涉及一个大系统的调整。

所以说，不能为了拆分而拆分，拆分的意图要准确描述问题的解决。在一个系统里面，定义接口比怎么实现更重要，不要设计不好理解、不合理的接口。