前言
从本节课开始我们将进入学习SpringCloud Micro-Service阶段。本节我们将进入了解和学习一下有关Micro-Service Basic Points.
架构
在软件/WebService开发的中关于架构的说法业内一般分为单体架构/SOA/微服务，不过随着技术堡垒的突破和发展，在未来肯定会出现更为优秀的架构。
单体
- 定义： 一个归档包例如war格式包含了应用所有功能的应用程序我们通常称之为单体应用架构单体应用的方法论我们称之为单体应用架构。
- 缺点
- 复杂性高
整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐，整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个BUG都会造成隐含的缺陷。 - 技术债务
随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。 - 部署频率低
随着代码的增加，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低，从而又导致两次发布之间会有大量功能变更和缺陷修复，出错概率较高。 - 扩展能力受限
单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。 - 阻碍技术创新
单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。
- 复杂性高
SOA
定义
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。
SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
优缺点：参考这里
微服务
定义：微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。参考原文
特点
- 每个微服务可独立运行在自己的进程里
- 一系列独立运行的微服务共同构建起了整个系统
- 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等
- 微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用
优点
- 易于开发和维护。一个微服务只关注一个特定的业务功能，所以它的业务清晰、代码量较少。开发和维护单个微服务相对比较简单，整个应用是由若干个微服务构建而成，所以整个应用也会维持在可控状态
- 单个微服务启动较快。单个微服务代码量较少，所以启动会比较快
- 局部修改容易部署。单体应用只要有修改，就要重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可
- 技术栈不受限。在微服务中，我们可以结合项目业务及团队的特点，合理地选择技术栈
- 按需伸缩。我们可以因也业务需要横向地扩张整个系统，使得系统的扩张性更好。
- DevOps。自动化运维（DevOps），在微服务架构中有许多用户维护各个微服务正常工作的组件来实时监听微服务健康状况以及整个架构的健康状态。
缺点
- 运维要求较高。更多的服务意味着更多的运维投入。在单体架构中只需要保证一个应用的正常运行；而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，带来了巨大的挑战。
- 分布式固有的复杂性。使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都带来了巨大的挑战。
- 接口调整成本高。微服务之间通过接口进行通信。如果修改某个微服务的API，可能所有使用了该接口的微服务都需要做调整。
- 重复劳动。很多服务可能都会使用到相同的功能。而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，导致代码重复。
微服务设计原则
AKF拆分原则
- AKF扩展立方体（参考《The Art of Scalability》），是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。
- X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。
- Z 轴：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。
- Y 轴：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。
- 场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。
前后端分离原则
前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP ，把Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。前后端分离原则带来的好处：
- 前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好
- 分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护
- 前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的web UI 移动App等访问
无状态服务原则
- 定义：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。
- 那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
- 场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
REST通信风格原则
作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的Restful 通信风格，选择RESTful 通信风格有点：
- 无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案HTTPS可用
- JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好
- 语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一些RPC框架生态更完善。
小结
- 随着技术创新和实际业务需求的发展，单体服务暴露的缺点越来越明显也越来越致命，在选择架构时慎重选择单体架构，若维护的是单体系统那就没办法啦。
- SOA和Micro-Service 存在着一定的联系，Martin Fowler人家也说过 Micro-Service的改进的出发点和要求都是源自SOA。就目前来看微服务做的还短让人满意。