微服务架构简述

• 单体架构
  单体系统或者单体应用，所有的应用功能耦合在一个应用中。
  运行时以一个进程来运行
  单体架构的优点是：项目易于管理，部署简单
  缺点：项目结构复杂功能体系庞大时，测试成本高，维护困难，更改困难伸缩性差。
  可靠性差，迭代困难，跨语言程度差。=
  常见的架构风格：
  1、客户端服务器架构
  2、基于组件模型的架构（EJB）
  3、分层架构（MVC）
  4、面向服务的架构（SOA）
• 微服务：
  1、系统有多个服务构成
  2、每个服务可以单独独立部署
  3、服务之间松耦合，服务内部高内聚，每个服务只关注完成一个功能。
  优点：解决了单体架构面临的问题
  易于测试、伸缩性强、可靠性强，跨语言、易于迭代、团队协作强。
  缺点：
  运维成本高，部署困难，接口兼容多版本，分布式系统复杂性，分布式事物。
  MVC架构：
  就是单体架构，代表性的而技术有：SpringMVC，Structs2,Spring，MyBatis
  RPC架构:
  远程过程调用，通过网络从远程计算机上请求服务，而不需要了解底层网络技术协议。
  代表技术：Thrift、Hessian:基于Http协议的轻量级RPC协议。服务间没有通信，当服务数量较多时难于管理。
  SOA架构：
  Servers oriented Architecture:面向服务的架构。在RPC的基础上多了ESB（Enterprise Servers Bus),提供了服务之间的交互
  ESB包含了：负载均衡、流量控制、加密处理、服务监控、异常处理、监控告警等
  代表性技术：Mule、WSO2、
  微服务架构：轻量级的服务治理方案类似于SOA，将ESB改成了zk/eureka(相对于ESB更轻量)
  代表技术有Spring Cloud、Dubbo等。
  三、微服务设计原则：
  1、AKF原则：可扩展系统的理念是通过增加机器或者集群设备类解决容量和可用性的问题，AKF扩展立方，将微服务拆分。
  Y轴拆分按服务拆分，将应用分成不同的服务。即拆分应用的功能，基于不同的业务拆分
  X拆分，即水平扩展，也就是扩展系统，负载均衡。对部分服务进行集群处理。
  Z拆分，数据分区以及单元化：根据业务需要将有个客户需求作为一个单元，自成一体。将数据集划分成不同的分区，根据不同的数据类型。比如说不同的城市作为一个数据分区，而不同城市的数据分区又是所有城市的数据的子集。
  2、前后端分离原则：前后端部署分离，各系运维只需要提供统一的接口即可，格子完成各自的构建。
  3、无状态服务：将有状态的数据服务迁移到有状态数据操作区，而把无状态的计算服务分离出来。（数据操作和计算分离，这样就不需要考虑数据缓存和同步的问题了)
  4、RestFul通信风格：服务间的通信，无状态的通信原则，如Http协议就是一个无状态通讯协议，安全的Https,json序列化报文轻量简单，人机均可读，语言无关各大热门语言都提供了RestFul的API框架。