### 什么是微服务 微是指小的意思，服务是一个独立运行的单元组件，每个单元组件运行在独立的进程中，组件与组件之间通常使用HTTP这种轻量级的通信机制进行通信； 微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力 ### 微服务拆分维度 针对微服务架构，普遍达成的共识是从业务角度驱动服务的识别与分解，我称其为微服务的“业务维度” ### 微服务主要功能 * 服务的注册和发现 * 服务的负载均衡 * 服务的容错 * 服务网关 * 服务配置管理 * 链路追踪 * 实时日志 ### 微服务架构的优点 * 每个服务都比较简单，只关注于一个业务功能。 * 微服务架构方式是松耦合的，可以提供更高的灵活性。 * 微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。 * 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。 * 微服务架构是持续交付\(CD\)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性 ### 微服务架构的缺点 * 运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。 * 必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。 * 隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。 * 代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。 * 分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。 * 异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。 * 可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意 ### 微服务架构三大难题 * 服务故障的传播性：熔断机制 * 服务的划分 * 分布式事务 _**参考资料**_ [https://www.ibm.com/developerworks/community/blogs/3302cc3b-074e-44da-90b1-5055f1dc0d9c/entry/解析微服务架构\_一\_什么是微服务?lang=en](https://www.ibm.com/developerworks/community/blogs/3302cc3b-074e-44da-90b1-5055f1dc0d9c/entry/解析微服务架构_一_什么是微服务?lang=en) [http://blog.didispace.com/20160917-microservices-note/](http://blog.didispace.com/20160917-microservices-note/)