一、SOA与微服务架构
SOA是面向服务的思维模式，将程序的功能抽象为服务，并通过服务间定义良好的接口规范将代表不同功能的服务联系起来，通过服务的标准封装复用达到业务的复用性目标。SOA可以通过不同的技术来实现，之前比较流行的WebService，它将HTTP协议看成传输层协议，在其基础之上定义应用层协议如SOAP等，用XML格式封装数据。它将多个系统整合通过ESB（企业服务总线）整合成一个服务，使用集中式架构，单体架构部署（业务耦合在一起部署），应用粒度大，适用于服务规模相对较小。
微服务架构和SOA的思想差别不大，更强调实现的轻量化，服务粒度更细，这里的“微”可理解为服务或应用的粒度更细。实现上它多采用基于HTTP协议的（HTTP看成应用层协议）RESTful API通讯。它通常将系统拆分为多个服务，粒度小，各服务功能独立，独立部署，服务自治，架构松散，使用服务规模膨胀，需要服务治理。
传统单体架构，多采用MVC三层架构（视图层、业务逻辑层、数据访问层），将整个应用视为一个整体部署在一个Web容器中，便于开发维护。但随着系统规模不断扩大，业务需求不断增多，它的维护成本增加，部署升级影响变大，可扩展性差，技术选型替换成本高。因此随着敏捷开发、持续交付、DevOps理论的实践，微服务架构应用而生，让应用架构朝着高可用性、扩展、可伸缩方面发展演进。它的好处是每个微服务职责单一，方便小团队开发维护，单个微服务故障影响小，方便分析做水平与垂直扩展，甚至每个服务可独立选择自己的技术架构。
二、微服务初级设计指南
如何拆分微服务？一般按业务功能拆分，每个微服务具有业务的独立性与完整性。尽可能减少服务依赖，实际开发时可先将服务的粒度设计的大些，并考虑其扩张性，随着业务发展，再动态地拆分优化。
微服务的数据库管理如何做？各微服务都有自己的缓存和数据库，并且不同服务间缓存和数据库应该是透明的，如果微服务A要调用B的数据，应通过B提供的接口进行。只有在特殊场景比如就服务升级时可让新的微服务房访问旧服务的数据库从而达到功能与数据过度的需求。
服务多版本设计时考虑在url中使用版本号，来区分不同版本API，并尽可能兼容之前几个版本的API接口。
为了应对微服务的链式调用异常，我们需要在设计微服务调用链时不宜过长，以免客户端长时间等待，以及中间环节出现错误造成整个请求失败。此外，可以考虑使用消息队列进行业务解耦，并且使用缓存避免微服务的链式调用从而提高该接口的可用性。
为了快速追踪定位问题，应采用全局的异常结构响应信息，出错时能方便的定位到时哪个微服务的哪类异常问题。
微服务的授权一般可采用OAUTH2.0协议，一定时间内有效的token认证方式。
三、前后端分离与跨域问题
目前的前后端分别就是简单的前后端分离方案，前段发送Ajax请求，服务端接受到请求后返回JSON数据到客户端，客户端解析JSON进行页面渲染。
常用的跨域解决方案有:JSONP（只支持get请求）、CORS（跨域资源共享，需要服务端、浏览器同时支持，IE8、9不支持）、搭建中间转发层，Nginx反向代理。
HTTP协议的幂等性是指一次或多次请求对资源的副作用相同，而不一定是返回结果相同，其中Get请求对资源无副作用，是幂等的，Put、Delete多次操作对资源的副作用相同，也是幂等的，Post操作多次操作副作用不同，不是幂等的。在RESTful API 接口设计时要根据实际情况考虑是否对POST类型请求做资源防重复提交逻辑的设计处理。
524
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
