## 一、背景 ***软件架构，总是在不断的演进中...*** 把时间退回到二十年之前，当时企业级领域研发主要推崇的还是**C/S模式**，PB、Delphi这样的开发软件是企业应用开发的主流。随着时间的推移，基于浏览器的**B/S架构**开始渐渐流行了起来。初期，Web开发ASP还占据了不少优势，但JSP的预编译模式让性能有了很大提升，随后基于JAVA语言的**J2EE架构**变得越来越流行。 早期软件架构基本都是**单体架构**，系统之间往往不需要进行交互，这也导致数据孤岛和ETL工具的发展。随着企业应用越来越多，相互的关系也越来密切，应用之间也迫切需要进行实时交互访问，随后基于XML的异构系统集成和数据交互技术开始被很多公司采用，SOA的概念被提了出来，web service逐渐流行。 互联网时代，很多公司为了适应更加灵活的业务需求，基于HTTP协议和Restful的架构风格及简洁和结构清晰的JSON语言成为企业开发的最佳实践，在SOA架构中，企业服务总线技术ESB所暴露的集中式架构的劣势让开发者明白基于注册和发现的分布式架构才是解决问题的关键办法。由此，微服务架构开始盛行。 在《微服务设计》中如何界定一个微服务，就是使用松耦合&高内聚原则，把因相同因素变化的事情聚集在一起，把因不同因素变化的事情区隔开来。 ## 二、微服务架构特性 微服务，其实是一种架构风格... ### 2.1 异构 服务不同最适合的技术方案不同，微服务可以帮助我们轻松采用不同的技术，并且理解这些新技术的好处。尝试新技术通常伴随着风险，但对于微服务系统而言，总会存在一些地方让你可以选择一个风险最小的服务采用新技术，并降低风险。 ### 2.2 隔离 微服务架构将系统分解为独立运行单元，给系统带来更好的隔离性，独立的微服务在发生异常时更容易定位和隔离问题，隔离性也是服务扩展性的基础。 ### 2.3 扩展 庞大的单体服务只能作为一个整体进行扩展，即使系统中只有一小部分模块存在性能问题，也需要对整个系统进行扩展。而微服务架构可以根据性能需要对不同的模块进行水平扩展，微服务的弹性也可以很好地处理服务不可用和功能降级问题。 ### 2.4 部署简单 在微服务架构中，各个服务的部署是独立的，这样就可以更快地对特定部分的代码进行部署。服务出现问题也更容易快速回滚，同时敏捷的交付和部署带来了更好的业务需求响应体验。 ### 2.5 灵活 在微服务架构中，系统会开放很多接口供外部使用，当情况发生改变时，可以使用不同的方式构建应用。而整体化的应用程序只能提供一个非常粗粒度的接口供外部使用。把单体应用分解成多个微服务，可以达到可复用、可组合的目的。 ## 什么是微服务？ 微服务是一种软件架构模式，用于将大型整体应用程序分解为更小的可管理独立服务，这些独立服务通过跨语言的协议进行通信，每个服务都专注于做好一件事情。 来自行业专家的微服务的定义。 1. 松散耦合的面向服务的体系结构 --Adrian Cockcroft 2. 一种将单个应用程序开发为一套小型服务的方法，每个小型服务都运行在自己的进程中，并与轻量级机制进行通信 --Martin Fowler 微服务的概念并不新鲜，这是对面向服务的体系结构的重新构想，而是采用了一种更加全面的方式与unix进程和管道对齐的方法。 微服务架构的理念： * 这些服务是小的 - 作为一个单一的商业目的的细粒度，类似unix哲学的“做一件事，做得好” * 组织文化应该包含部署和测试的自动化。这减轻了管理和运营的负担。 * 文化和设计原则应该包含失败和错误，类似于抗脆弱的系统。 ## 为什么需要微服务？ 随着组织规模技术和人数的增长，管理单一代码库变得更加困难。我们都已经习惯了在一段时间内整个Twitter失败，因为他们试图用一个单一的系统来扩展他们的用户群和产品功能集。微服务使Twitter可以将他们的应用程序分解成更小的服务，这些服务可以由许多不同的团队分别管理。每个团队负责由许多可独立于其他团队部署的微服务组成的业务功能。  我们已经看到了第一手的经验，微服务系统可以缩短开发周期，提高生产力和优越的可扩展系统。 我们来谈谈一些好处： 1. **更容易扩展开发** - 团队围绕不同的业务需求组织管理自己的服务。 2. **更容易理解** - 微服务要小得多，通常为1000 LOC或更少。 3. **更容易频繁地部署新版本的服务** - 可以部署，缩放和独立管理服务。 4. **改进的容错和隔离** - 关注分离可以最大限度地减少一个服务中的问题对另一个服务的影响。 5. **提高执行速度** - 团队通过独立开发，部署和管理微服务来更快地实现业务需求。 6. **可重复使用的服务和快速原型** - 微服务中的unix理念使您能够重用现有服务，并更快地构建全新的功能。