1.关于微服务架构service mesh，它比起传统的微服务架构有那些优势的地方
Service mesh被用来处理服务间通讯的专用基础设施层，通过复杂的拓扑结构让请求传递的过程变得更可靠。
Service mesh通常作为一组轻量级高性能网络代理，这些代理和程序代码部署在一起，但是应用程序不需要对代理有任何动作。
Service mesh是一个网络模型，它是位于TCP/IP之上的抽象层。它假定底层的L3/L4网络是真实存在的，并且能够点对点地传递字节。
但与TCP不同的是，Service mesh具有更高的性能。
Service mesh最终并不是引入一项新功能，而是功能定位的转变。Web应用程序总是必须管理服务间通信的复杂性。
你可以思考下2000年的中型web应用程序的典型架构: 三层应用程序。 在这个模型中，应用程序逻辑、web服务逻辑和存储逻辑都是单独的一层。 层之间的通信虽然复杂，但这种复杂性是限定在一定范围内，因为毕竟只有两个跳转。这里没有“网格”，但是在每个层的代码中处理的跳转之间有通信逻辑。
当这种架构方式在面对应用程序内部逻辑越来越复杂化的情形时，它就开始崩溃了。 像Google、Netflix和Twitter这样的公司无时无刻都面临着巨大的流量需求，它们实现了云原生方案的前身: 应用层被分解成许多服务(有时称为“微服务”)，层级间则形成了一个拓扑结构。 在这些系统中，广义的通讯层突然变得相关起来， 但通常以“胖客户端”的库集（library）形式出现， 比如twitter的Finagle，Netflix的Hystrix，以及Google的Stubby就是这样的例子。
从很多方面上来讲，像Finagle, Stubby和Hystrix这些库集其实是Service mesh的雏形。虽然它们受其周围环境的细节影响，并且需要使用特定的语言和框架，但是它们是用于管理服务到服务间通信的专用基础设施，并且(在开源Finagle和 Hystrix库集的情形下)可以在其公司之外使用。
到了云原生应用时期， 云原生模型本身结合了许多小型服务的微服务方法和两个额外的因素:容器(例如Docker)，它提供了资源隔离和依赖关系管理，以及一个编排层(例如Kubernetes)，它将底层硬件抽象出了一个同质池。
这三个组件支持应用程序在负载下可弹性伸缩的自然机制， 并能够处理云平台环境中存在的部分故障。
但面对数百个服务或数千个实例，和随时在重新安排实例的编排层，单个请求经由服务拓扑的路径可能非常复杂， 而由于容器使每个服务用不同的语言写入处理变得更容易了，库集方法也就不再可行了。
这种复杂性和关键性的结合，激发了对服务到服务间通信的专用基础层的需求，这个专用层与应用程序代码分离出来，并能够捕捉底层环境的高度动态特性。就是这一专用层我们称之为Service mesh
2.这个也是个设计问题，首先是业务必须熟悉，然后可以根据领域模型进行领域划分，拆分可以根据AKF扩展立方体（Scalability Cube），
这个立方体有三个轴线，每个轴线描述扩展性的一个维度，他们分别是产品、流程和团队：
X轴 —— 代表无差别的克隆服务和数据，工作可以很均匀的分散在不同的服务实例上；
Y轴 —— 关注应用中职责的划分，比如数据类型，交易执行类型的划分；
Z轴 —— 关注服务和数据的优先级划分，如分地域划分。
微服务的4个设计原则和19个解决方案
三个维度扩展的对比
通过这三个维度上的扩展，可以快速提高产品的扩展能力，适应不同场景下产品的快速增长。不同维度上的扩展，有着不同的优缺点：
1.X轴扩展
优点：成本最低，实施简单；
缺点：受指令集多少和数据集大小的约束。当单个产品或应用过大时，服务响应变慢，无法通过X轴的水平扩展提高速度；
场景：发展初期，业务复杂度低，需要增加系统容量。
2.Y轴扩展
优点：可以解决指令集和数据集的约束，解决代码复杂度问题，可以实现隔离故障，可以提高响应时间，可以使团队聚焦更利于团队成长；
缺点：成本相对较高；
场景：业务复杂，数据量大，代码耦合度高，团队规模大。
3.Z轴扩展
优点：能解决数据集的约束，降低故障风险，实现渐进交付，可以带来最大的扩展性。
缺点：成本最昂贵，且不一定能解决指令集的问题；
场景：用户指数级快速增长。
如何将理论付诸实践？
1.为扩展分割应用
X轴：从单体系统或服务，水平克隆出许多系统，通过负载均衡平均分配请求；
Y轴 ：面向服务分割，基于功能或者服务分割，例如电商网站可以将登陆、搜索、下单等服务进行Y轴的拆分，每一组服务再进行X轴的扩展；
Z轴 ：面向查找分割，基于用户、请求或者数据分割，例如可以将不同产品的SKU分到不同的搜索服务，可以将用户哈希到不同的服务等。
2.为扩展分割数据库
X轴：从单库，水平克隆为多个库上读，一个库写，通过数据库的自我复制实现，要允许一定的读写时延；
Y轴 ：根据不同的信息类型，分割为不同的数据库，即分库，例如产品库，用户库等；
Z轴 ：按照一定算法，进行分片，例如将搜索按照MapReduce的原理进行分片，把SKU的数据按照不同的哈希值进行分片存储，每个分片再进行X轴冗余。
3.为扩展而缓存
在理想情况下，处理大流量最好的方法是通过高速缓存来避免处理它。从架构层面看，我们能控制的主要有以下三个层次的缓存：
对象缓存：对象缓存用来存储应用的对象以供重复使用，一般在系统内部，通过使用应用缓存可以帮助数据库和应用层卸载负载。
应用缓存：应用缓存包括代理缓存和反向代理缓存，一个在用户端，一个在服务端，目标是提高性能或减少资源的使用量。
内容交付网络缓存：CDN的总原则是将内容推送到尽可能接近用户终端的地方，通过不同地区使用不同ISP的网关缓存，达到更快的响应时间和对源服务的更少请求。
4.为扩展而异步
同步改异步：同步调用，由于调用间的同步依赖关系，有可能会导致雪崩效应，出现一系列的连锁故障，进而导致整个系统出现问题，所以在进行系统设计时，要尽可能的考虑异步调用方式，邮件系统就是一个非常好的异步调用例子。
应用无状态：当进行AKF扩展立方体的任何一个轴上的扩展时，都要首先解决应用的状态问题，即会话的管理，可以通过避免、集中和分散的方式进行解决
其实微服务的事务就是分布式事务，刚性事务和柔性事务。
刚性事务是指严格遵循ACID原则的事务, 例如单机环境下的数据库事务。
柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 两阶段提交(2PC), TCC补偿型提交, 基于消息的异步确保型, 最大努力通知型.。
分布式事务的各种实现方式：
如果业务场景需要强一致性, 那么尽量避免将它们放在不同服务中, 也就是尽量使用本地事务, 避免使用强一致性的分布式事务.
如果业务场景能够接受最终一致性, 那么最好是使用基于消息的最终一致性的方案(异步确保型)来解决.
如果业务场景需要强一致性, 并且只能够进行分布式服务部署, 那么最好是使用TCC方案而不是2PC方案来解决