微服务目的是做到服务可随时动态扩缩。有以下三种策略服务拆分,水平扩展,水平复制。
微服务架构把这三个维度比喻成一个立方体。
使用负债均衡平衡后端服务。后端服务多为单体,水平扩展用于克隆单体。
而如果后端有缓存的关系(cookie或者服务端保存会话,是保存在内存中,而不是数据库),就不能适用水平扩展或者不能只简单地水平扩展,所以这个水平扩展更新用单机服务的扩展。
X轴的水平扩展很好实现,一般用tcp四层代理和http7层代理,4层和7层的区别在于
tcp四层代理不需要状态,7层更适用于检查http头或者一些值来达到平衡。
应用场景:
一开始没考虑扩展的服务,当运行到某个瓶颈时候,优先考虑这种简单粗暴的水平扩展
app proxy应用代理或者 application delivery controller (ADC)应用流量分发控制器
代理把计算型服务,也常见于在云应用场景中。
单体功能拆分成服务。它也是个典型的7层负载均衡
Y轴扩展(功能扩展),把功能拆分成服务;又通过SOA和RESTful api把服务组合成功能
Y轴扩展是一个前置条件是,ADC流量分配器从uri区分。
一个功能扩展和水平扩展相结合的例子是:
z扩展是介于X和Y扩展,使用基于数据分片的策略,
z扩展在每个节点都运行同样一份程序,这种有点像X水平扩展,但是和X水平扩展不一样的时候,Z扩展服务的数据段不一样,
基于访问数据段来分发流量。
这种z扩展是基于访问数据的流量分发,所以也适用于高级的vip用户得到更好的服务。
sage是a sequence of local transactions. 一个服务提交完自己的数据库,将数据流向 下一个服务。使用异步消息来协调本地事务。
维持跨服服务一致性的传统方式是分布式事务,两阶段提交保证事务中的所有参与方都可以完成提交,或者在失败时同时回滚。
很多流行组件不支持分布式事务NoSql(Cassandra ,MongoDB),RabbitMQ, Kafka。所以传统的分布式事务不能完美兼容一些流行组件。
把SAGA的决策和执行顺序逻辑分布在sage的每一个参与方中,他们通过交互事件的方式进行沟通
把saga的决策和执行顺序集中在一个sage编排器勒种。saga编排器发出命令式消息给个个saga参与方,指示这些参与方完成具体操作(本地事务)
下载源码
git clone https://github.com/eventuate-tram/eventuate-tram-sagas.git
这个项目是采用gradle编译工具链(一个java编译框架),编译设定属性在gradle.properties文件。
进入源码目录执行./build-and-test-everything.sh ,这个文件背后调用了设置环境变量,然后调用gradlew编译。
在编译之前需要安装java8、docker-compose、docker。java8是用来当jvm。docker*是安装mysql、zookeeper、kafka的组件服务。
,解决办法:确保安装的是java8,而不是java11
安装完多个版本的java,可以用以下命令切换:
gradle daemon模式是编译会在后台启动一个daemon服务,用于加快持续集成编译,下次编译会利用上次编译的缓存,编译得更快。但是这个问题其实本质是内存不足。我一开始用1G的云服务器编译,都是这种诡异的问题,换到4G内存的云服务器编译,这些问题都消失 了,这个架构背后还会docker启动zk、kafka和mysql服务,以及jvm编译环境都是比较耗内存的。所以建议是这里用4G以上的内存机器进行编译。
这个是没有安装docker,需要按照官网的指导正确安装docker和docker-compose。配置yum源如果是centos服务器的话。然后yum安装完docker,记得service docker restart启动。然后还需要安装python pip服务,使用pip安装docker-compose
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。