分布式id生成器java
近几年热门讨论的低代码，甚至无代码，只是一个噱头吗？
近几年热门讨论的低代码，甚至无代码，只是一个噱头吗？
低代码平台在国内是近几年开始火起来的。从开发角度来说，我对这个东西是嗤之以鼻的。
近一段时间我都在研究这一类东西，原因是公司老总们被这个东西忽悠的五迷三道，不可自拔。低代码作为一个营销概念来说，极为符合老总们的理念，也就是其所谓的 快速搭建，轻松适配，看起来能缩短开发周期，节省部署维护成本，省了钱，自然合了老总的意。
但是，这些低代码平台的弱点都被巧妙的隐藏起来了。借由动态解析渲染的低代码平台注定性能不会好，固化且不成熟的表单(数据库表)设计逻辑注定对大数据量和复杂业务的支撑极为难看。可悲的是市面上的大多数产品都是如此，加上整体架构过时，设计不成熟，使用场景受限严重。其中HW的AppCube这一类是考虑的比较多的，但是学习成本丝毫不低，而且也有他自己的相应问题。
公司购买了一个低代码平台并使用其搭建了一个项目，最终由于性能，数据量支撑，兼容性等等问题，项目上线前大量功能都重新转为自研，返工严重，研发团队也出现了不稳，可谓是赔了夫人又折兵。老总们才终于能够意识到了这东西有坑。
如果低代码未来还是现在这种水平，无法突破，那么，
想你的技术团队解散么，给他们买低代码平台~
想你的公司业务垮掉么，给研发买低代码平台~
想体验事倍功半么，给公司建议买低代码平台~
低代码有毒~ 粗略来说业务线核心数据规模百万级以上，并发200以上，切勿以身范险。
纯粹增删改查倒是蛮合适的，但其实编码成本也没多少。
鸡肋，食之无味弃之可惜。
服务治理平台难点突显，如何助力企业微服务架构落地？
伴随互联网、云计算、大数据等技术的快速发展，越来越多的企业在信息化之后，将企业上云和数字化提上日程。随之而来，软件架构的微服务方式重构、应用的自动化运维、容器化等强烈需求，催生出了众多的PaaS平台。
服务治理平台难点突显
同时，针对微服务，也涌现出了许多RPC框架和微服务治理平台，各个框架和平台都有各自的优势和自身独特的适应场景。
微服务除了开发期框架之外，还有需要一系列的运行期中间件支撑，如API网关、服务注册中心、统一配置中心等。
为解决微服务应用运行期治理问题，还需要有如服务监控，全链路追踪等相关方案。此外，落地还需要解决一些分布式架构带来的问题，微服务的分布式特征，如保持一致性的分布式事务、业务幂等性，全局唯一ID生成等。
为实现快速上线（持续部署等目标），还需要DevOps工具链，以及运行环境的对服务弹性，优雅上下线，灰度发布等功能的支持。最后，还需要微服务拆分，团队组织，职责划分等一系列的方法学支持。比如康威定律，两个披萨原则。
东软有个团队就是研究这个的