• 嗯，学习云原生相关，整理课堂笔记记忆
• 学习原因： 云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。作为Java开发来讲，微服务是大多数行业都要涉及的开源技术栈
• 博文主要内容涉及： 企业应用架构的演进:单体地狱、SOA，微服务架构,当然微服务并不是“银弹"，典型的微服务框架介绍Springclound之类
• 食用方式： 博文全是理论，适合对微服务的技术体系初学或者理论温习如果希望系统学习，这里推荐《微服务架构设计模式》一书，看了一点，个人感觉不错
• 理解不足小伙伴帮忙指正

傍晚时分，你坐在屋檐下，看着天慢慢地黑下去，心里寂寞而凄凉，感到自己的生命被剥夺了。当时我是个年轻人，但我害怕这样生活下去，衰老下去。在我看来，这是比死亡更可怕的事。--------王小波

应用向CloudNative(云原生)演进，微服务是CloudNative的事实标准。

• 第一代是单体架构，当然它有很多例如紧耦合、封闭架构等各种各样的问题。
• 第二代是SOA架构，可能大型企业级的应用里面会比较多，提供了很多种支持，实际上我们看到SOA架构的时候，它已经强调松耦合了。但是没有彻底解耦，存在服务总线
• 第三代微服务架构，它实际上是变得更加灵活了。在业务变化非常快速的背景之下，微服务架构是一个非常好的解决方案，微服务的核心一敏捷、灵活、精准弹性。 微服务架构出现的最大的意义是不断地提高交付效率，缩短交付周期。

从架构师的角度：微服务架构就是把一个大系统按业务功能分解成多个职责相对单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。

在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

从技术专家的角度：微服务架构就是把相同业务领域或因相同原因而变化的功能聚合到一起，而把不同业务领域或因不同原因而变化的功能分离开并利用轻量化机制（通常为HTTP RESTful APl）实现通信。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。

2014年，Martin Fowler与James Lewis共同提出了微服务的概念（实际上2009年Netflix就已经开始实践微服务了，但是当时没有微服务一词），定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。同时服务会使用最小的规模的集中管理（例如Docker）能力，服务可以用不同的编程语言与数据库等组件实现。

• 微服务架构是一种架构模式，将单体应用划分成一组小的服务，通过服务之间互相协作，共同实现系统功能·
• 每个服务运行在其独立的进程中，服务间采用轻是级的通信机制协作（通常是基于Restful Apl）。
• 每个服务都围绕着具体业务进行构建，由独立的小团队负责设计、开发、测试，并可以独立部署到生产环境·