系统上线
loader
系统改造需求
interface
application
1.每个spi对应一个loader，loader会加载这类spi的所有实现接口2.这个spi可以定义多个扩展点，每个扩展点会被不同的流程用到，每个扩展点对应一个实现类。3.拿到loader，通过扩展点的名字，获取对应扩展点，这个扩展点就实际上使用对应的实现类。4.当然，如果你的扩展点实现类，函数被adaptive注解，函数必须有个dubbo的url参数，这样基于url拿到的命名，可以拿到对应的扩展点来实现。
SPI
@spi 注解就是一个个扩展点我们就是要基于扩展点，实现扩展点，然后实现功能的扩展。扩展有两个注解要学习：1、@adative2、@active第一个是通过字节码的方式，按照配置实时获取对应的字节码实现。第二个是说明扩展点的生效场景，一般是应用在filter这种场合。同时还支持了AOP和IOC。
系统开发
系统监控
系统定位
data
系统测试
entity
进程1
系统设计
首先要区分1、接口层的统一有业务返回码和业务返回信息。业务成功统一返回COM00000其余情况返回业务返回码业务返回码的分类：1.1、技术原因失败1.2、业务原因失败 例如：查对象为空，是因为这个对象的确不存在，还是因为技术或者网络原因导致查不到，这个要区分清楚。1.3接口层的交互应该分成三类，query operation event2、application层可以通过异常返回。具体码值按照原有规范继续执行。常见的全公司公用的业务返回码应该统一起来。系统，然后加上公共的定义即可。注意就是网关要做的改造，lsf要做的改造。公共的错误码，分成两类1、技术类的。网络超时，认证失败，参数错误，数据量太大，访问频率过高，被调用系统内部错误。2、业务类的。按照每个业务域抽取出2到3个，数据不存在。1、 不采用两层码，统一叫业务返回码2、 对调用方，超时，区分网络不通、服务挂掉、服务处理过久超时的情况3、 变量平台这种批量查询的，单独考虑4、 系统内部非rpc调用，可继续使用异常5、 各系统的工程整合按规范（中间的业务组件和技术组件）6、 是否重试由调用方决定7、 交易系统（蔡啸），治理。治理放大风险的代码。改动量不大。8、 具体的码值可以继续保留，只是一个代号。----公共的一些通用码，可以明确定义好，其他的由开发人员自定义。 -----老王看了提了这些意见，同步给你
微内核
进程2
