微服务“微服务”已经成为软件架构中最流行的流行语之一。在网上看到了很多关于微服务的文章，但是感觉很多都离我们还很遥远，在企业场景中真正应用的例子我也没找到多少。这里省略10000字~~~~所以想把最近一段时间使用微服务的心得和读高手的文章整理一下，分享给大家参考（热切欢迎大家拍砖，流血是最好的）。1、什么是微服务？请记住，当您第一次看到微服务时，您应该关注微词，然后才是服务。初步的理解是：将整个服务拆分成多个类似工具的微小web服务，为了调用其他服务，每个服务都应该非常小，就像每个部分一样，各司其职，组装成一个很大的服务群。由于本人是技术出身，不太注重理论，所以根据自己初步的理解，走向“微服务”（这里需要引述，否则会被批）。首先，它实现了微服务的多种构建方式。听说有springboot、jersey+jetty、Python、NodeJS等等。然后了解到微服务主要是基于restful风格的架构来提供服务（还有Thrift），rest的实现是HTTP“请求-响应”，rest是一种基于资源的API风格，然后我们就可以理解为微服务是多个能够表示资源和对该资源执行的操作的集成的服务。既然是对资源的使用和操作，每个微服务就应该是一个独立的个体。基于以上理解，我迫不及待地想用“微服务”来实现自己的业务需求。以一个简单的客户信息管理系统为例：主要是客户信息管理、用户管理、组织架构管理等（这里不多举例）。按照前面的理解，客户、用户、组织架构应该是三种不同的资源，所以应该分为三种不同的微服务。但是在某一层组织结构下，会有多个用户，某个用户又会有自己的多个客户，所以没有办法将三个服务完全分开（它们还是有关联的），这不符合前面的要求明白了。但是在业务关系上，三者之间的联系是必不可少的，它的存在也是合理的，所以应该是三个微服务之间相互协作又相互独立的关系。就像团队成员之间的协作关系一样，他们既独立又相互依存。总结：微服务是基于Restful风格，基于资源集合和资源操作一组API，可以在特定业务范围内实现模块或完全独立、细粒度、自包含的服务。每个微服务都提供一组API供其他微服务或应用程序客户端使用。2、什么是微服务架构？既然提到了微服务架构，那么单体应用架构和SOA架构也就不得不说了。1、什么是单体应用：说到单体应用，我们举个例子。典型的单体应用程序包括ERP、CRM、BPM和其他软件。对于ERP和大型CRM应用，一个软件可能包含数百个功能点。这类软件的开发、维护、部署、纠错、扩容、升级，对于相关人员来说都是一个不小的麻烦（噩梦）。2.什么是SOA架构SOA是解决单体应用问题的架构：SOA是一种面向服务的定义良好的接口和它们之间的契约。由于每项服务由不同的功能单元组成，因此该服务的范围非常广泛。SOA架构类似于微服务架构，以至于国外很多人使用微服务，因为他们认为微服务只是对SOA的二次包装。SOA和微服务的篇幅我就不在这里讨论了。大概要讨论三天三夜吧~~~3.什么是微服务架构从表面上看，微服务架构范式与SOA非常相似。包括一组服务。然而，微服务架构范式被视为没有某些能力的SOA。这些功能包括Web服务描述(WS-)和企业服务总线(ESB)商品化和请求包。基于微服务的应用程序更喜欢简单、轻量级的协议，如REST而不是WS-。他们还强烈避免在微服务中使用ESB和类似功能。微服务架构范式也拒绝SOA的其他部分，例如规范模式的概念（来自“ChrisRichardson微服务系列”）。3、微服务架构的优缺点微服务架构的好处是可以解决复杂性的问题。在功能不变的情况下，可以分解成多个相互协作的微服务，通过restAPI定义边界，非常容易开发、理解和维护。微服务架构意味着每个服务都可以由专门的开发团队或个人开发人员开发。开发者可以自由选择技术，不受指定的技术和框架的限制，只要API服务协议有利于交互（比如restful）即可。这样，重新技术过时的微服务模块或重写以前的代码并不是很难。微服务架构模式使得每个微服务独立部署，每个服务独立扩展，开发者不再需要协调其他服务部署对服务的影响。微服务架构模式让持续部署成为可能。微服务架构不足“微服务”强调的是服务的规模，所以很多人都把注意力放在了“微”这个词上。虽然小型服务更容易被采用，但微服务只是结果，而不是最终目标。微服务的目的是有效拆分应用，实现敏捷开发和部署。微服务应用是分布式系统，必然会带来内在的复杂性。开发者需要选择协议消息传递规则，完成进程间通信。与单体应用相比，微服务下的这项技术更加复杂。关于微服务的数据库架构，由于同一个事务更新多个业务是很常见的，这种事务操作对于单体应用来说很容易解决，因为只有一个数据库。在微服务架构中，由于每个微服务使用不同的数据库，使用分布式事务不一定是好的选择。而当前高度可扩展的NoSQL数据库和消息中间件不支持这样的需求。由此，对开发者提出了更高的要求和挑战。由于微服务架构的分布式特性，测试基于微服务架构的应用程序也是一项非常复杂的工作。为单个微服务测试一组RESTAPI相对简单，但通常涉及启动与其相关的所有服务。因此，采用微服务架构带来的不仅仅是敏捷的开发和部署，也带来了一定的复杂度。在微服务架构模式下，应用的变化会影响多个服务。例如，假设你正在完成一个需求，需要修改服务A、B、C，A依赖B，B依赖C。在单体应用中，你只需要更改相关模块，集成更改,并部署。相比之下，微服务架构模式需要考虑相关变更对不同服务的影响。例如，您需要更新服务C，然后是B，最后是A。幸运的是，许多更改通常只影响一个服务，需要跨多个服务协调的更改很少见。部署微服务应用程序也非常复杂。单个应用程序只需要在复杂的平衡器后面部署自己的服务器。每个应用实例都需要配置数据库、消息中间件等基础服务。相比之下，微服务应用程序通常由大量服务组成。根据AdrianCockcroft的说法，Hailo包含160种不同的服务，而Netflix则有600多种服务。每个服务都有多个实例，这会产生大量的配置、部署、扩展和监控。另外，你还需要完成一个服务发现机制，发现与之通信的服务地址（包括服务器地址和端口）。传统的问题解决方法无法解决如此复杂的问题。归根结底，成功部署一个微服务应用需要开发者对部署方式有足够的控制力和高度的自动化。（摘自《ChrisRichardson微服务系列》）根据上一点的描述，在微服务架构的应用中，往往会有很多微服务实例，而每个服务又有多个实例，那么服务的自动部署必然与服务的发现机制也需要解决。参考文章Microservicesinpractice:Createmicroservicesfromarchitecturetodeployment?请刘英光先回答这10个问题@火蜜工作室OpenBI交流群：495266201MicroService微服务交流群：217722918邮箱：liuyg#liuyingguang.cn博主主页（==防止爬虫==）：http://blog.liuyingguang.cnOpenBI问答社区：http://www.openbi.tk
