Java基础之《微服务（1）—为什么要用微服务》

一、单体架构

1、什么是单体架构
单体架构也称为单体系统，它就是把所有功能，所有模块都耦合在一个系统里面，它部署打包为一个独立单元（例如打包为jar或war），它最大的特点就是整套系统只有一个进程。

2、单体架构特点
（1）测试、部署问题
测试、部署成本高：业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署
（2）伸缩性
可伸缩性差：单体架构系统由于单进程的局限性，水平扩展时只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。
例如：电商系统，包含了用户、商品、订单、交易、支付；如果商品的访问量非常大，我想对商品进行集群部署，这时你是无法做到，你只能对整个系统进行集群部署。
（3）可靠性
可靠性差：某个BUG，例如死循环、内存溢出，会导致整个进程宕机，影响整个系统，影响其他功能。
（4）系统迭代
迭代困难：由于所有的功能都在一个系统里面，会导致日常迭代相当困难，例如互联网项目，多个项目每月都有一次正常迭代，必定导致代码分支过多，分支合并代码繁琐困难。
（5）跨语言程度
整个系统（甚至整个企业）统一的技术栈，管理起来看似简单。但有时候统一的标准并不适合所有的实际情况。
（6）团队协作
整个系统一个团队，如果系统变得庞大，成员就需要学习大量的代码和领域知识，团队内的沟通和协作也变得低效。

二、微服务

1、什么是微服务
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。

2、什么是架构风格
架构风格是一种设计模式，是一种系统级的设计模式，而不是代码模块的设计模式。
常用的架构风格一般有4种：
（1）客户端-服务器：将系统分为两个应用，其中客户端向服务器发送服务请求。
（2）基于组件的架构，例如EJB
（3）分层架构，例如MVC
（4）面向服务架构，例如mule、dubbo、springcloud

3、微服务架构特点
（1）测试、部署问题
每个微服务组件都是简单灵活的，能够独立部署。不像单体系统，需要一个庞大的应用服务器来支援。
（2）伸缩性
微服务之间是松耦合，微服务内部是高内聚，每个微服务很容易按需扩展。水平扩展只要按服务进行扩展即可。
（3）可靠性
不会因为某个bug，而导致整个系统宕机。因为服务之间是松耦合的关系，不是强依赖。
（4）系统迭代
由一个小团队负责更专注专业，相应的也就更高效可靠。每个微服务可以由不同的团队独立开发。
（5）跨语言程度
微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。
（6）团队协作
团队按微服务配置。成员专注于小的领域和代码集。沟通成本低。容易学习。

4、微服务架构带来的问题
（1）运维成本过高，部署物数量多、监控进程多导致整体运维复杂度提升。
（2）接口兼容多版本（面向服务开发，就是面向接口开发，一般接口的变更，必然导致多个客户端要跟着改，那怎么办呢，就必须做接口的多版本开发）
（3）分布式系统的复杂性（本来就一个系统，把他拆成多个服务，就会引发，网络不稳定延迟、服务容错性差、服务的负载均衡等等）
（4）分布式事务（微服务开发，带来的难题就是分布式事务的处理，关于分布式事务业界也有很多处理的方法）

三、MVC、RPC、SOA、微服务的架构区别

1、区别

2、一家公司创业历程
（1）创建时3个人
刚起步，为了试错，架构选择MVC
（2）经过一年发展，得到A轮融资
技术人员变成20个人，架构升级为RPC框架
（3）RPC升级为SOA
什么是ESB

 ESB是用来干嘛的？
提供一些基础服务，例如：负载均衡，流量控制，缓存，事务，加密传输，安全管理等等
（4）又经过一年发展，得到B轮融资
技术人员变为80个人，架构升级为微服务

四、微服务设计原则

1、AKF拆分原则

（1）微服务拆分方式：
见图Y轴所示方式，即按照不同的服务功能进行拆分。
（2）微服务拆分要点：
低耦合、高内聚：一个服务完成一个独立的功能。
按团队结构，小规模团队维护，快速迭代。
（3）AKF扩展立方体（参考《The Art of Scalability》），是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩容。
Y轴（功能）：就是按功能进行拆分，它基于不同的业务拆分。
X轴（水平扩展）：将微服务运行多个实例，做个集群加负载均衡的模式。
Z轴（数据分区）：基于类似的数据分区，比如一个互联网打车应用突然火了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。

2、前后端分离

前后端分离原则，简单来说就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。
不要继续以前的服务端模板技术，比如JSP，把Java、JS、HTML、CSS都堆到一个页面里，稍微复杂的页面就无法维护。
这种分离模式的方式有几个好处：
（1）前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。
（2）分离模式下，前后端交互界面更加清晰，就剩下接口和模型，后端的接口简洁明了，更容易维护。
（3）前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模板，可以支撑多个前端：例如微信h5前端、安卓、IOS。

3、无状态服务

（1）什么是状态
如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。
进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。
（2）无状态服务
那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
（3）场景说明
例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。
迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

4、无状态通信—Restful通信风格

Restful通信风格的好处
（1）无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密，有现成的成熟方案HTTPS可用。
（2）JSON报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
（3）语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一些RPC框架生态更完善。
（4）当然在有些特殊业务场景下，也需要采用其他的RPC框架，如thrift、avro-rpc、grpc。但绝大多数情况下Restful就足够用了。