前几天公司生产环境因为外部请求过大或者说恶意攻击，导致数据库服务器CPU资源耗尽，几乎处于宕机状态，随后应用服务器出现大量请求超时，日志系统崩溃，最终整个产品无法对外提供服务（包括汇款、转账、充值等核心业务），好在运维小哥哥给力，及时解决了这次事故，不然我也不知道结果会怎么样...
其实此次事故在我看来是预料之中的事情。为什么这么说？其一，架构存在一些问题，其二，微服务治理能力比较薄弱，其三，技术更新有点慢，当然这个不是绝对的啊，只要团队实力强，而且老板愿意花钱和时间投入也是可以写出稳定高效的架构，最后一点，服务拆分的慎重，越多越难管理，或者说是否可以考虑抽象出业务中台？以上只是个人的一点看法，没有任何其他意思，也绝对没有否定这个架构的意思，任何一种架构或者技术都是在不断迭代、试错、重构之后，才会慢慢趋向成熟稳定。在我眼里，任何一种架构框架只要能上线生产运营那他就是成功的。相反，会说的“架构大神”我见过很多，会做的，尤其是那种从无到有能做出来上线的真没几个，下面简单提些建议吧。
1. 分期重构，产品需要稳定运营，老板需要挣钱，事情的一件一件做，拆分出核心业务，如汇款、充值、转账等等相关业务，确保核心业务能实现三高指标，这个实现起来还好，没那么的麻烦，集群部署，多级缓存，重构分布式日志系统（ exceptionless、elk），业务上集成熔断降级策略，针对大表并且读多写多的业务做读写分离，或者分库分表（水平垂直，结合业务），反正一期的目标很明确，就是确保核心业务的三高指标。
2. 网关服务重构迁移到core，网关个人认为存在一些问题，解包，序列化和反序列化，导致代码冗余，性能下降，而且增加复杂度，网关应该干它专业的事，建议直接上ocelot开源产品，性能谈不上出色，但是开源可控，Grpc，服务发现等高级功能也有相应的扩展包，如果后期快速发展，需要迁移到envoy等专业网关产品，也可以以最小的代价直接平移。
3. 链路跟踪，目前公司有几十个服务，服务太多，调用链太长，定位问题确实很困难，需要经验，需要逻辑推理，才能大概定位到问题，诸如此类问题已经碰到几回了，以后还会经常发生，所以我们需要一款APM工具，通过dashboard可以快速发现问题，定位问题，解决问题，或者先从运维这边切入，集成prometheus服务资源监控工具，也是可以的。这里顺便提一下，. 微软也有监测服务，并且集成到了azure，好像要收费吧。
4. 服务监控，目前公司的服务器资源很多，如redis、mq、mysql、nginx、服务器等等，这些资源目前没有被统一的监控起来，出了问题还是比较原始的方案，通过阿里邮件告警的方式，然后再定位到具体的资源，然后再定位问题，往往到了这个时候，也快接近宕机了。如果我们的资源被统一监控起来(prometheus)，那么我们可以自定义告警系统，如redis、mysql的qps、内存、健康状态、延迟等等指标达到多少，然后通过邮件、钉钉的方式告警，争取处理时间，还可以通过多种维度的数据统计软硬资源指标，达到事先预判的效果。
5. 服务发现，目前现有的方案是DNS解析+Nginx转发的方式，当然这种方案在请求量不大的情况下也没有太大问题，就是在细节控制、性能等方面有些问题，建议集成三方开源的服务注册发现中间件，如zookeeper、consul、eureka这三个当中的任意一个都可以，他们都是开源稳定的产品，社区也很活跃。