这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记
在课程中老师讲解了关于微服务架构的开发，让我受益良多，在这里简单记录一下我对微服务开发的一些认知。
架构选择
微服务架构区别于传统的单体软件架构，是一种为了适应当前互联网后台服务的「高并发、高性能、高可用」而产生的的软件架构。
单体应用
与微服务相对的另一个概念是传统的单体式应用程序，单体式应用内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性，也就是相互依赖彼此，很难拆分和扩容。
作为学生，我们之前在课程上写的很多程序本质上都是单体式应用程序，从简单的Hello World程序到一个大的网站开发。
单体应用程序的优点
- 开发简洁，功能都在单个程序内部，便于软件设计和开发规划。
- 容易部署，程序单一不存在分布式集群的复杂部署环境，降低了部署难度。
- 容易测试，没有各种复杂的服务调用关系，都是内部调用方便测试。
单体应用程序的缺点
单体程序的缺点一开始不是特别明显，项目刚开始需求少，业务逻辑简单，写代码一时爽，一直爽。噩梦从业务迭代更新，系统日益庞大开始，前期的爽没有了，取而代之的是软件维护和迭代更新的无尽痛苦。
由于单体式应用程序就像一个大型容器一样，里面放置了许多服务，且他们都是密不可分的，这导致应用程序在扩展时必须以「应用程序」为单位。
当里面有个业务模块负载过高时，并不能够单独扩展该服务，必须扩展整个应用程序（就是这么霸道），这可能导致额外的资源浪费。 此外，单体式应用程序由于服务之间的紧密度、相依性过高，这将导致测试、升级有所困难，且开发曲线有可能会在后期大幅度地上升，令开发不易。相较之下「微服务架构」能够解决这个问题。
微服务
微服务 (Microservices) 就是一些协同工作小而自治的服务。
2014年，[Martin Fowler] 与 [James Lewis]共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 [Docker]) 能力，服务可以用不同的编程语言与数据库等组件实现 。「维基百科」
面向服务的体系结构 SOA (Service-Oriented Architecture) 听起来和微服务很像，但 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间，最终 SOA 看起来很美，小公司却难以应用。
此外，SOA时会遇到很多问题，比如通信协议（例如SOAP)的选择、第三方中间件如何选择、服务粒度如何确定等，目前也存在一些关于如何划分系统的指导性原则，但其中有很多都是错误的。SOA并没有告诉开发人员如何划分单体应用成微服务，所以在实施SOA时会遇到很多问题。
这些问题再微服务框架中得到很好的解决，你可以认为微服务架构是SOA的一种特定方法。
合久必分，鉴于「单体应用程序」有上述的缺点，单个应用程序被划分成各种小的、互相连接的微服务，一个微服务完成一个比较单一的功能，相互之间保持独立和解耦合，这就是微服务架构。
微服务优点
相对于单体服务，微服务有很多优点，这里列举几个主要的好处：
- 技术异构性，不同服务内部的开发技术可以不一致。
- 隔离性，一个服务不可用不会导致另一个服务也瘫痪，因为各个服务是相互独立和自治的系统。
- 可扩展性，可以只对那些影响性能的服务做扩展升级。
- 简化部署，在微服务架构中，各个服务的部署是独立的。
- 容易优化，微服务架构中单个服务的代码量不会很大，当需要重构或者优化这部分服务的时候，就会容易很多。
微服务缺点 微服务架构不是万能的，并不能解决所有问题，其实这也是微服务把单体应用拆分成很多小的分布式服务导致的，带来了在开发和运维管理上的高复杂度，这也是在用微服务架构时不可避免地问题。
