微服务微服务是指提供单一业??务功能的服务。从技术角度看，它是一个小而独立的加工过程。类似于进程的概念，可以独立启动或销毁，有自己独立的数据库。一个复杂的软件架构是由许多小型且独立运行（具有自己的端口）的微服务组成的。这些独立的处理组件之间的通信是通过与语言无关的API进行的。简单协议有同步RMI/RPC和RESTfulWebServices，异步消息推送和Reactive模式。这些模块化的方法使公司能够将项目分解和分散到多个开发团队，在不同业务部门之间提供足够的灵活性，有助于改善项目生命周期，加快项目开发和完成的效率。每个微服务组件都有自己分配的存储内存和CPU资源，这使得硬件利用率更容易优化和跟踪，特别是在基于云的Pass环境中，开发团队可以使用他们喜欢的技术，任何语言都可以，只要确保微服务是交互式的，可以组合后续应用程序。当通过采用微服务架构降低管理复杂性时，通常更新其中一个微服务组件不会引起连锁反应，因为微服务是松散耦合的。目前使用微服务的企业包括：Netflix、Twitter、亚马逊网络服务（AWS）、谷歌、eBay等。由于很多应用和服务部署在基于云主机的环境中，微服务架构将严重依赖容器技术。容器将微服务处理过程隔离开来，将一个应用程序分割成小的实例。这些容器中的小实例一个实例有自己的端口和虚拟化环境。广泛使用的容器技术是Docker，它是一种基于Linux的开源实现，得到Canonical、RedHat和Parallels等多家软件公司的支持。PaaS服务支持包括GoogleAppEngine、RedHatOpenShift和VMware的CloudFoundry。微服务架构不仅仅是传统服务越来越小。微服务的两个显着特点是：微服务本身是无状态的；微服务之间几乎没有可变共享。可以想象，如果微服务可以共享，会带来两个问题：微服务团队需要协作，因为共享的是统一的数据库。如果这种共享不带来沟通成本，不破坏一个团队的目的，那么也可以考虑这种共享数据库，但这种情况很少见，大多数团队因为共享问题破坏了独立性；而且，如果使用Docker将微服务打包到一个容器中，这些容器可能会部署在不同的基础设施上，部署方式非常灵活。是云原生应用，共享数据库属于底层基础设施，显然增加了部署难度。另外，传统服务之间的通信，无论是RPC/RMI，还是Http/RESTful，都是同步的，而微服务之间的通信应该是异步的或者reactive，即异步。根据FLP不可能原理，网络默认是不可靠的。一旦发生网络拥塞，RPC将连续爆炸。事后监控并不能从根本上解决这个问题。需要从CAP定理的角度进行平衡设计，引入事件驱动或者Pub/Sub消息方式。它可以在提高网络容错能力的同时保证数据的最终一致性。灵活的事务是微服务环境的主要选择。由于事务处理要求，传统服务往往变得单一。某个服务方法代码很多，需要塞在同一个事务边界。这样虽然带来了高一致性，但是可扩展性比较差，因为一??个服务器内的同一个事务边界Action不能拆分成几个微服务。因此，要使用微服务，必须积极拥抱最终一致性，并对分布式系统和CAP定理有一定的了解。当然这些只有在必须有多个微服务调用的时候才需要考虑。由于微服务体积小，具体，共享继承的思想可以用组合代替，代码的重复性可以容忍。一个微服务架构需要满足以下条件：基础监控度量和健康检查分布式日志跟踪对于每一个服务来说，不仅仅是代码的隔离，还有构建+测试+打包+提交的全过程。可以清晰的定义每个服务的上下游、编译时和运行时的依赖关系。掌握如何构建、公开和维护良好的API和合约。b/w和f/w兼容性都需要得到尊重，即使您可能不是您提供的服务的消费者。良好的单元测试和更多的可读性注意微服务与模块和库包之间的区别，以及分布式单体、协作版本发布和数据库驱动继承之间的区别。知道基础设施自动化需要基于CI/CD持续集成/持续交付的基础设施服务划分：根据业务能力定义服务范围根据领域驱动设计中子域的概念定义服务范围通信方式：使用RPC-基于同步通信方法使用异步消息进行服务间通信外部API：API网关（APIgateway）——为每一类客户端提供唯一的接口来访问服务前端后端（Backendforfront-end）——用于每种客户端都提供独立的API网关数据管理：每个服务都有自己的私有数据库专用接口服务共享同一个数据库使用事件保持服务间数据一致性事件溯源/CQRS运维监控：服务发现：使用第三方-party模块将服务实例信息注册到服务注册中心。分布式追踪（Distributedtracing）新增——对于服务代码中的每一次外部访问，分配一个服务标识符，在跨服务访问时传递这个标识符，用于跟踪分布式触发断路器（CircuitBreaker）——当故障率返回时远程服务超过一定阈值，客户端代理（如API网关）会立即返回失败信息给远程服务的调用
