本期分享嘉宾：
滨雨
多年IT领域工作经验，先后在华为、阿里基础架构部担任软件工程师、项目经理。目前从事存储、cdn、视频、中间件等技术领域的支持，喜欢新技术，喜欢新挑战，喜欢钻研。
-
攻城狮：谁又动了我模块接口？谁又改了我模块逻辑？？？
-
运维：有bug！模块之间的调用跟个蜘蛛网一样，我怎么排查！
-
测试：这么复杂的调用逻辑，我的自动化测试用例咋写？！
-
架构师：业务上升了，系统要部署到多台服务器才行，这我怎么拆？！
-
新人入职后：代码太难理解，想shi的心都有了…….
-
老板：为啥大半年过去了需求还没搞定！！！
作为一个开发者，你是否经历过这样的咆哮？
这样的场景出现，不是谁的脾气有bug，而是打开方式或许不对。今天我们就通过一个真实案例，来看看分布式开发对消灭吐槽，促进团队和谐的作用。
单体应用很丰满，现实很骨感
X公司是一个秉承传统的开发方式的典型，如下图的架构图是一个实际场景中的架构图，按照传统的开发方式，业务模块层按照“高内聚低耦合”的原则划分成不同的模块，所有模块的开发人员都是在一个大工程下进行编码测试，模块之间的业务划分的很清晰。
X公司架构图
但理想是丰满的，现实很骨感，按照很“完美”的模块划分后，在一个大的应用工程下进行开发进行开发，但随着系统功能越来越强大，，软件复杂度急剧增加，开发人员的新旧交替，慢慢的单体应用给开发团队、产品发展等造成的直接弊端，系统维护变得异常艰难。
一切不完美，都可以坦然面对
在这种情况下，估计很多的开发团队估计都会想到用分布式应用来解决。但是，分布式应用就一定是完美的吗？答案当然是否定的。分布式应用也难免存在很多问题，例如：
- 如何保证服务之间调用链路的稳定性
- 如何保证服务调用安全性
- 遇到应用需要扩容时候该怎么办
- 应用拆分了，都需要单独部署，我能怎么更方便管理应用部署问题
- 服务调用的性能能保证吗
- 毕竟是由本地调用改为了rpc方式，我需要怎样更方便的监控调用链路呢？
- 分布式事务的问题要如何解决呢？
这些问题其实如果要全部解决，也是个浩大的工程。还好，不完美的世界不需要一个人面对，总有些人在寻找解决方案。比如阿里云中间件产品EDAS，就是为分布式开发的不完美提供了不少解决方案。
什么是EDAS
企业级分布式应用服务（Enterprise Distributed Application Service, 简称 EDAS）以阿里巴巴中间件团队多款久经沙场的分布式产品作为核心基础组件，面向企业级云计算市场提供高可用分布式解决方案，是阿里巴巴企业级互联网架构解决方案的核心产品。
EDAS架构解密
- EDAS控制台：对用户操作层，以及对外提供api服务的系统
- 数据收集系统：包括链路监控、服务监控、基础监控等数据的采集存储和分析
- 配置注册中心系统：开发分布式应用所依赖的注册中心，包括服务端和消费端服务信息、服务地址信息、配置信息等
- 监控报警：可以提供报警支持，自定义报警规则，确保业务有风险时负责人能第一时间收到消息
EDAS能做什么
1、搭建分布式应用系统
快速基于EDAS开发好分布式应用，减少大量开发工作，应用可以是服务提供者，也可以是服务消费者，也可以两者都是
2、应用生命周期管理
3、链路调用监控
实际的大型系统中，都有很复杂的业务链路调用，如果将单体应用重构为分布式应用后，没有一套良好的监控体系，在系统出现问题时定位问题将会异常困难。如图是一个实际场景下的链路调用：
EDAS 鹰眼监控系统能够分析分布式系统的每一次系统调用、消息发送和数据库访问，从而精准发现系统的瓶颈和隐患
根据应用来监控到链路调用信息
从具体监控信息定位到影响性能的环节
4、分布式事务
当应用拆分成分布式架构后，难免会遇到分布式事务问题，阿里云也提供了对应的产品解决这个问题，全局事务服务（Global Transaction Service，简称 GTS），是一款高性能、高可靠、接入简单的分布式事务中间件，用于解决分布式环境下的事务一致性问题。
经过多年的发展和实践，EDAS等中间件产品已经在阿里内部得到广泛的应用，如图所示的案例场景：
X公司开发案例实战
像开头说到的，当系统到达一定规模后，软件复杂度急剧增加，维护也将变得异常艰难。如何用挽救X公司于水深火热之中？下图是将业务拆分后一部分业务架构：
A公司架构图
其中，将资产中心和鉴权中心采用docker部署的方式，docker部署的方式可以支持一台服务器上部署多个应用，这样也有利于节省硬件成本，提高资源利用率。
业务开发
代码工程划分
整体思路是提供一个公共的接口应用，作为公共引入的jar包（这只是其中一种开发模式），其他每个应用一个工程，采用maven工程的模式来开发。本地开发时，如果几个应用工程都在同一个环境下，可以将几个groupId都指向同一个，方便调试。下图是工程划分：
接口应用开发
在接口应用中将需要被不同应用引用的实体以及需要对外暴露的接口都定义好。如图所示
创建好后eclipse工程如截图：
部分代码片段：
引入接口工程
将tradeshop-api工程打成jar包发布到maven仓库，在其他三个工程pom文件引入：
<dependency>
<groupId>com.alibaba.edas.tradeshop</groupId>
<artifactId>tradeshop-api</artifactId>
<version>1.0.2</version>
</dependency>
资产中心开发
产中心要实现的业务是能够被交易中心调用、获取资产信息，所以资产中心需要做的是实现获取资产信息的接口业务，并且用hsf标签对外注册提供服务。例如简单的业务实现代码为：
代码实现后，就需要将服务对外暴露，供服务消费端来调用：
需要注意的是，发布的服务中version和group固定了，那么消费端在调用的时候，这两者的值必须保持统一。
鉴权中心开发
鉴权中心实现的业务是提供对外的接口用来查询鉴权信息，那么也是需要对外暴露一个服务，开发方式跟资产中心类似，可以参考资产中心的开发。
交易中心开发
交易中心需要有两方面的作用，一是对外暴露服务用于查询交易信息，一个是充当消费端，主动去调用其他服务。充当服务端的代码开发模式和前两个应用类似，充当消费端去调用资产中心和鉴权中心的，就可以采用spring bean加载的方式获取到接口service，然后当做本地方法来调用，如核心代码：
将依赖的服务和需要发布的服务配置，注意版本号和分组值，以及接口名不能写错。
用户中心开发
用户中心在本案例中充当业务入口，去调用交易服务，所以用户中心只需要注册消费一个服务即可：
消费代码：
业务验证
参考EDAS官网文档，创建好应用，并成功将应用部署到线上后，可以在EDAS控制台上很方便的进行业务验证，链路跟踪，也就能很方便的定位到平时业务之间链路的瓶颈所在。
应用服务验证
当应用部署成功后，可以在控制上看到提供的服务和调用的服务，也可以在应用控制台上看到业务运行的日志，如截图所示
同样也可以查看到应用中的http服务、hsf服务信息：
服务链路验证
通过链路监控，可以很直观的监控到整个业务调用的状态，及时的定位到问题出现的地方
好了，一套简单的分布式应用系统就开发完成了，so easy！X公司的故事，也不出意外的迎来了happy ending。
