标签：
微服务“Microservices”已经成为软件架构最流行的热词之一。网络上看到很多关于微服务的文章，但是感觉很多离我们还很遥远，并且没有找到多少真正在企业场景中应用的实例。此处省略一万字~~~~于是想要将自己最近一段时间使用微服务以及通过看大师们的文章的所思所想梳理出来，分享出来，以供大家参考（热切欢迎大家拍砖，头破血流最好）。
记得刚看到微服务的时候，注意点在微字上，然后才是服务，初步理解为：将整块儿的服务拆分成多个类似工具类的微小web服务，供其他服务调用，每个服务应该是极其微小的，就像各个零件一样，各司其职，拼装成一个伟大的服务群
由于自己是技术出身，对理论并不是很重视，于是基于初期的理解，就向着“微服务”（这里要打引号，不然会被拍板砖）迈进。先是实现了微服务的多种搭建方式，听说有springboot的、有jersey+jetty的、有Python的、有NodeJS的等等。进而了解到，微服务主要是以restful风格架构以提供服务（还有Thrift），rest的实现是HTTP的“请求-响应”，而rest是基于资源的API风格，进而可以理解微服务是多个能够表现对一个资源及对此资源执行的操作集成的服务。既然是对一个资源的使用及操作，那么每个微服务应该是独立的个体。
基于以上理解，迫不及待的使用“微服务”来实现自己手上的业务需求，就拿简单的客户信息管理系统为例：主要有客户信息管理、用户管理、组织架构管理等（这里不多举例）。根据之前的理解，客户、用户、组织架构，应该是三种不同的资源，那么应该分为三个不同的微服务。可是某一层组织架构下，会有多个用户，而某个用户又会拥有属于自己的多个客户，如此并没有办法将三个服务彻底分离（还是有关联关系），这不符合之前的理解。然而业务关系上，三者的联系必不可少，存在即合理，那么也理应是三个微服务互相协作而又相互独立的关系。如同团队成员之间的协作关系，相互独立而又相互依赖。
小结：微服务是基于Restful风格的，基于资源及资源操作一组API的集合，可以实现模块儿或者说是特定的业务范围内的一个完全独立、细粒度、自包含的一个服务。每个微服务提供一组API，供其他微服务或者应用客户端所用。
说到单体应用，直接举例来说吧，典型的单体应用有ERP、CRM、BPM等软件。对于ERP和大型的CRM应用来说，可能一个软件就包含有数百个功能点。对于此类软件的开发、维护、部署、纠错、扩展及升级对于相关人员来说都将是大麻烦（噩梦）。
SOA是解决单体应用架构的问题的一个解决方案：SOA是面向服务的体系架构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。既然每个服务是有不同的功能单元组成，那么这个服务的范围就非常广了。
SOA架构与微服务架构比较相似，以至于国外不少人范围微服务的原因是认为微服务只是对SOA的二次包装。这里不去讨论SOA与微服务的长短，这个要讨论估计要三天三夜了吧~~~
表面上看，微服务架构范式与 SOA 非常类似，这两种架构都包括一套服务。然而，微服务架构范式被看作不包含某些功能的 SOA 。这些功能包括网络服务说明（ WS-* ）和 Enterprise Service Bus (ESB) 的商品化和请求包。基于微服务的应用更青睐 REST 这样简单的、轻量级的协议，而不是 WS-* 。他们也极力避免在微服务中使用 ESBs 及类似功能。微服务架构范式也拒绝 SOA 的其它部分，比如 canonical schema 的概念（摘自“Chris Richardson 微服务系列”）。
可以解决复杂性的问题，在功能不变的情况下，分解为多个相互协作的微服务，通过rest API定义边界，这样极大易于开发、理解和维护。
微服务架构是的每个服务可以由专门的开发团队或者个人开发者进行开发，开发者可以自由选择技术，不必受制于规定的技术和框架，只要API服务协议好交互方式即可（如restful）。这样即使重新技术过时的微服务模块儿或者重写以前的代码，也不是很困难。
微服务架构模式使得每个微服务独立部署，且每个服务独立扩展，开发者不再需要协调其它服务部署对本服务的影响。微服务架构模式使得持续化部署成为可能。
“微服务”强调了服务大小，所以很多人的关注点主要在“微”字上，尽管小服务更容易被采用，但是微服务只是结果，而不是最终目的。微服务的目的是有效拆分应用，实现敏捷开发和部署。
微服务应用是分布式系统，必然会带来固有的复杂性，开发者需要协议消息传递规则的选择并完成进程间通讯。相对于单体应用，微服务下这种技术显得更加复杂一些。
关于微服务的数据库架构，由于同一事务更新多个业务很普遍，这种事务操作对于单体应用来说很容易解决，因为只有一个数据库，而在微服务架构中，由于每个微服务使用不同的数据库，使用分布式事务并不一定是好的选择。并且现在高扩展性的NoSQL数据库和消息传递中间件并不支持这样的需求。从而对开发者提出了更高的要求和挑战。
由于微服务架构的分布式特点，测试一个基于微服务架构的应用也是很复杂的任务。测试单个微服务的一套REST API 相对简单，但是往往要启动与之相关的所有服务。所以，采用了微服务架构带来的并不仅仅是敏捷开发和部署，还会带来一定的复杂性。
微服务架构模式下，应用的改变将会波及多个服务。比如，假设你在完成一个需求，需要修改服务A、B、C，而A依赖B，B依赖C。在单体应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A。幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。
部署一个微服务应用也很复杂，一个单体应用只需要在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相比之下，一个微服务应用一般由大批服务构成。根据 Adrian Cockcroft 的分享，Hailo 由 160 个不同服务构成，而NetFlix则超过600个服务。每个服务都有多个实例，这就形成大量需要配置、部署、扩展和监控的部分。除此之外，你还需要完成一个服务发现机制，以用来发现与它通讯服务的地址（包括服务器地址和端口）。传统的解决问题办法并不能解决这么复杂的问题。最终，成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化。(摘自“Chris Richardson 微服务系列”)
根据上一点的描述，在微服务架构的应用中，往往有很多个微服务实例，并且每个服务都有多个实例，那么服务的自动化部署必然与服务发现机制同样要解决。
标签：
原文地址：http://blog.csdn.net/gsying1474/article/details/52176360
