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