微服务

微服务

微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
一、微服务应用设计原则
（一）AKF扩展立方体：是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。
X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。
Z 轴 ：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。
Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。
（二）无状态服务：
什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。
那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
（三）无状态通信—Restfu API
Restful 通信风格 ：
无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案HTTPS可用。JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一些RPC框架生态更完善。当然在有些特殊业务场景下，也需要采用其他的RPC框架，如thrift、avro-rpc、grpc。但绝大多数情况下Restful就足够用了。
（四）前后端分离
前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP ，把Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：
前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。
分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的web UI\ 移动App等访问。
二、微服务带来的问题
（一）依赖服务接口变更
（二）部分模块重复构建：跨团队、跨系统、跨语言会有很多的重复建设。
（三）分布式带来的问题
（四）运维复杂度陡增：如部署物数量多、监控进程多导致整体运维复杂度提升。
三、关键问题
（一）安全认证
1、HTTP 基本认证：客户端发送 HTTP Request 给服务器。
2、基于 Session 的认证：基于 Session 的认证应该是最常用的一种认证机制了。用户登录认证成功后，将用户相关数据存储到 Session 中，单体应用架构中，默认 Session 会存储在应用服务器中，并且将Session ID 返回到客户端，存储在浏览器的 Cookie 中。
3、基于 Token 的认证：随着 Restful API、微服务的兴起，基于 Token 的认证现在已经越来越普遍。Token 和 Session ID 不同，并非只是一个 key。Token 一般会包含用户的相关信息，通过验证 Token 就可以完成身份校验。
基于 Token 认证的好处如下：
服务端无状态：Token 机制在服务端不需要存储 session 信息，因为 Token 自身包含了所有用户的相关信息。
性能较好，因为在验证 Token 时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。
（二）分布式事务
四、微服务架构的好处
（一）每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应用需要一个庞大的应用服务器来支撑。
（二）可以由一个小团队负责更专注专业，相应的也就更高效可靠。
（三）微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。
（四）微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。
五、微服务相关技术—Docker
Docker 是一个开源应用容器（目前也分为CE和EE版本，不完全开源化，也存在收费版本），让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
Docker 作为容器工具可以把：业务逻辑容器、数据库容器、储存容器、队列容器使得软件可以拆分成若干个标准化容器，然后像搭积木一样组合起来，让彼此通信，从而形成微服务。
​ 因此微服务很适合用 Docker 容器实现，每个容器承载一个服务。一台计算机同时运行多个容器，从而就能很轻松地模拟出复杂的微服务架构。
容器（Docker）与微服务：
（一）容器够小 –解决微服务对机器数量的诉求
（二）容器独立 –解决多语言问题
（三）开发环境与生产环境相同 –单机开发、提升效率
（四）容器效率高 –省钱
（五）代码/image一体化 –可复用管理系统
（六）容器的横向与纵向扩容 –可复制 –可动态调节CPU与内存