把以往的单体服务中的某些模块拆分出来，每一个模块都是单体的功能，模块之间相互之间又相互有一些依赖，之间会有相互的调用。
这种架构用WebService就能实现，称作SOA，单指服务治理的模型。
以往微服务主要的技术栈指SpringCloud，Dubbo
原来，我们把单体服务按照业务线拆分为组件，
后来，我们根据功能把系统拆分为模块，比如日志监控系统、上传文件功能
但这些都不叫微服务
单体模块在进行架构设计的时候，是独立的存在，不依赖任何其他功能
微服务功能之间没有任何的依赖：不主动、不拒绝、不负责
- 不主动去推数据，而是等别人来取——不主动，避免一致性问题、脑裂问题
- 跨平台的，基于Http的Restful的远程调用——不拒绝任何远程调用
- 如果别的服务来调用我，能不能调通，是别人的事情——服务的容错、重试，全部责任倒置，由调用方来负责
关于RPC
Dubbo做远程服务调用的时候是基于RPC的，传输的是Java序列化对象，不能跨平台（跨语言）
DubboX使用 http 传输 JSON，替代RPC，可以跨平台（跨语言）；XML也可以跨平台，但是效率更低
RMI：java本身提供了一种RPC框架
服务拆分原则、方法论仅供参考，一定要自己多拆…
业务线的拆分
要对用量瓶颈进行拆分，比如磁盘读写、网络带宽的使用（生成头像、下载报表）、计算密集型…可以把它们拆开，主要目的是在资源的使用上互不影响。
对于2M以上的报表、疯狂刷磁盘的业务，可以拆分出来。
基于技术栈的拆分
将文件上传、搜索服务、通知/推送服务、邮件服务 拆分出来，供所有业务使用。
前台：前端、接入层
后台：业务逻辑CRUD、数据库
中台，介于前台和后台之间，提供复用
可以分为技术中台、业务中台、数据中台
做中台的条件是之前的业务要有足够多，要有积累，才适合直接转化为多租户的服务
微服务的运维成本远高于单体应用
网关可以设置在整个系统的最外边（流量网关），也可以设置在系统内部（业务网关）
流量网关不能使用LVS，应该拥有识别功能（支持编写程序）AWF
可以使用Java（Tomcat、Netty），或Nginx+C+Lua
Tomcat 性能低，因为他要建立会话（上下文），不适合用来做网关
APR：异步网络传输
Nginx写的网关：用C/Lua写的
基于nginx的二次开发：用Lua语言写
可以nginx直接请求redis，返回html页面
https://tengine.taobao.org/
OpenResty
