项目简介：
现在做的项目，根据我们一开始的口号，就是国产替代。已看上去就觉得很牛逼，当时自己也是热血沸腾，觉得这个项目可能会有所不同。然而实际上到目前为止发现项目跟原来的口号根本不匹配。甚至还比不上其他部门不打这口号的项目。
论现在项目“失速”的原因有很多。主要总结一下几点，其实这篇文章的目的是看一下自己手中的牌到底是怎么样的一个烂牌。
第一个原因：项目不事先定立细节标准。从一开始我就尽力去劝HW SE，尽量定立一个规范去支撑我们的API的开发，甚至我们可以直接把其他部门的API标准直接搬过来。但是HW SE觉得，这啥标准，差不多就行了。
导致状况：风格迥异的API，有的甚至谈不上合理。
第二个原因：定立方案没有做充分的基准测试。序列化为了使方法简便，就直接用个Map，放着对象不用，甚至连JsonObject都不考虑（实际上也是Map的变种）。理由是HW SE 觉得Map比对象快。实际上通过微基准发现根本不是这一回事。
导致状况：实际上Map带来的负担远远大于HW SE 带来的益处。后面关于Map导致的对象不能被释放还没有体现出来。目前也没有内存监控测试方面去查这个问题。Map带来的调试困难，远比实例化对象要复杂。
第三个原因：决策失误。目标上，我们应该达到多少毫秒，通过这种方向来定立自己的实现方案，如果两个方向差不多就选择对问题定位更好的方案。实际上，我们从Map的选择就可以窥见一斑，我们选择微服务，不是因为我们真做微服务，而是觉得微服务吊，
觉得微服务流行而去选择的。紧接着为了迎合领导，上了一个四不像的DDD（领域驱动开发），中间各种对象的转化也就是去Copy实际产生的作用几乎为零，还拖慢的速度。然而Map就推翻了上面想要的结论，没有业务对象，只有Map一个。对于缓存的选择， HW SE倾向于自己写jvm缓存，而不是用现在主流的ehcache，放着redis不用，也是觉得慢。
跟我想的如果真在要实现国产替代，首先要做好的是自己要有足够的包容心，然后要细致的去用测试来支撑自己的结论，而不是猜，而不是就跟着理解来。决策失误往往就是太多自信导致的。
理想化的状态：
1.项目开始之前定立自己标准规范。
2.遵照个规范去定立自己API接口，并进行线上化管理。
3.定立好对象类图，仔细分析DDD，怎么运用在项目上，如果分析不好，后面改也行。不能强上。
4.对于微服务与单体项目做谨慎的评估，不能认为单体项目就是落后。无论哪种技术合适的才是最好的。
5.开发接口的时候，要考虑调用方怎么方便，尽量统一自己的风格（实际上这一步在API设计的时候就应该考虑好）。
6.开发过程中谨慎选择技术方案，实际上下结论之前做好，微基准测试并不是一件很困难的事情。
目前项目已经很难想理想的方向发展：
如果是我，我觉得项目应该是。首先定立好API规范，然后在设计中心对API进行线上化设计并且管理。无论是哪种接口，对内对外。紧接着选择Gson 作为项目工具，对象化合理设计为基准而不是用Map。 评估Redis与ehcache，选择一个或者综合两个作为我们缓存方案。或者直接用ehcache，项目变成单体应用。