Choerodon猪齿鱼

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文是Choerodon 的微服务系列推文第四篇，上一篇《 Choerodon的微服务之路（三）：服务注册与发现 》介绍了Choerodon的注册中心，并通过代码的形式介绍了 在Choerodon微服务框架中是如何来实现服务注册和发现的，本篇将介绍配置中心在微服务架构中的作用。 ▌文章的主要内容包括： 配置是什么 为什么需要微服务配置中心 Choerodon的配置中心 在早期单体应用的时代，监控等系统配置管理可能并不是什么困难的问题。但是在微服务架构中，和安全、日志、非功能需求一样，配置管理是一种非功能需求。配置中心也是整个微服务架构体系中的一个重要组件，即使它的功能看上去并不起眼，无非就是简单配置管理和存取，但它是整个微服务架构中不可或缺的一环。 在Choerodon的微服务体系中，如何通过更加高效的配置管理方式，帮助微服务系统进行配置规划，推动项目的持续交付，动态调整和控制系统的运行状态，这些问题都值得深入思考和研究。 配置是什么 在讲配置中心之前，首先提到一个核心的概念，就是服务的“配置”。配置可能各位都不陌生，一个配置项大多是key-value的形式，value可能是一个有限值的集合。Choerodon通过这些配置项，来控制系统的运行状态，可以说，配置其实是独立于程序的可配变量

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文是 Choerodon 的微服务之路系列推文第三篇。在上一篇《 Choerodon的微服务之路（二）：微服务网关 》中，介绍了Choerodon 在搭建微服务网关时考虑的一些问题以及两种常见的微服务网关模式，并且通过代码介绍了Choerodon 的网关是如何实现的。本篇文章将介绍Choerodon 的注册中心，通过代码的形式介绍 Choerodon 微服务框架中，是如何来实现服务注册和发现的。 ▌文章的主要内容包括： 服务注册/发现 服务注册表 健康检查 在上一篇文章的开始，我们提到解决微服务架构中的通信问题，基本只要解决下面三个问题： 服务网络通信能力 服务间的数据交互格式 服务间如何相互发现与调用 网络的互通保证了服务之间是可以通信的，通过对JSON 的序列化和反序列化来实现网络请求中的数据交互。Choerodon 的 API 网关则统一了所有来自客户端的请求，并将请求路由到具体的后端服务上。然而这里就会有一个疑问，API 网关是如何与后端服务保持通信的，后端服务之间又是如何来进行通信的？当然我们能想到最简单的方式就是通过 URL + 端口的形式直接访问（例如：http://127.0.0.1:8080/v1/hello）。 在实际的生产中，我们认为这种方式应该是被避免的。因为 Choerodon

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 由Choerodon猪齿鱼核心团队创立的 BuildRun （ https://gobuildrun.com ），基于猪齿鱼带来了多云架构环境下基于视觉的企业级应用创建、集成、部署、生命周期管理和分发的能力。 BuildRun 以云原生的现代化软件架构来帮助企业提升软件开发生产力和业务敏捷性，提供多云低代码应用平台和多云应用生命周期管理平台，帮助企业隐藏应用开发和运行时的基础架构复杂性，让每个人专注于业务逻辑，促进团队快速、持续地将想法转化为真正的商业价值。 团队在云原生技术和架构（DevOps、持续交付、微服务和容器）应用场景，如企业数字化转型、企业中台等方面拥有丰富的经验，公司客户包括商业地产、建筑工程、医药、家居、汽车配业、大型工业等企业，为您提供最合适的解决方案。 免费注册试用： https://apps.gobuildrun.com/#/base/register-organization 来源： oschina 链接： https://my.oschina.net/choerodon/blog/3141877

Choerodon猪齿鱼作为一个微服务框架需要解决微服务数据初始化本身具有的问题和复杂性，同时也需要满足框架本身特有的数据初始化需求，下面为大家介绍一下这方面的设计思想和实现。 微服务的数据初始化难题 先来看一下在微服务的数据初始化中常见的几个问题。 ▍1.1 表结构的初始化和可平滑升级 表结构的定义在数据库初始化中是重中之重，它涉及到整个服务运行和利用数据库实现功能的方式，一般来说表结构定义和升级涉及到以下操作：创建表，创建字段，创建索引，修改索引，修改字段，重命名表，删除索引，删除字段，删除表。这些操作如果都需要对多种数据库进行兼容和可平滑升级，那么复杂度就会突然增加，基本不可能像传统应那样通SQL脚本进行管理，而猪齿鱼面临的就是这种情况。 ▍1.2 跨服务数据的自动初始化 在微服务架构中，不可避免的会出现需要将数据初始化到其他服务的场景，比如猪齿鱼的大部分服务都需要初始化菜单数据到IAM服务，处理菜单列表的请求是由IAM服务处理的，然而对于微服务的部署而言，很多时候又不能运行初始化数据的时候连接多个数据源从而产生问题。而且微服务的部署可能不是全量的，存在这个部署不需要这个服务的情况，这种情况的初始化又需要修改初始化的脚本或者程序带来复杂性。 ▍1.3 繁琐的编码化数据的自动发现 数据的初始化中有一类数据是可以从代码或者文档，或者其它地方收集提取出来的

随着Choerodon猪齿鱼的不断迭代更新，它已经被越来越多的用户开始在项目管理和开发中使用，成为了开发团队的一部分。 这个过程中，有很多用户向团队提出一些关于敏捷管理上的问题，或者想了解猪齿鱼敏捷团队是怎么来进行项目管理的。 今天就来聊一聊这方面，以下内容请使用敏捷管理的项目经理或产品经理务必仔细阅读。 本文将以敏捷管理这个子产品团队为例，由敏捷管理的产品负责人亲自讲述，希望能给大家提供一些参考和帮助，从而改善团队协作，提升团队交付价值和开发效率。 团队组成 猪齿鱼旨在帮助团队进行敏捷化的应用交付和自动化的运营管理，由敏捷、测试、CI/CD、开发流水线、知识管理等多个子产品组成，除了各个子产品团队团队还有架构组这样的基础服务团队。每个团队根据开发工作量由6-10人构成。 敏捷管理团队从组建以来一直保持8-10人的规模，目前有6名开发人员（2前端，4后端）、1名产品负责人（PO）、1名UI设计师，所有人都全职投入在这个项目中，基本上不会有跨团队的情况发生。 开发节奏 整个猪齿鱼产品的所有团队都保持在同一个开发节奏上，2周一个迭代，2个迭代加上1周的持续改进，这样5周一个版本的速率稳定向前更新。 有人会问：为什么是2周而不是1周一个迭代呢？经过团队长期的验证，2周的时间可以开发一些较为复杂的需求，并且还能完成测试验收。 当然，没有准确的标准说1周好还是2周好，这个可以通过团队的磨合

“我们使用敏捷开发。”在与软件开发团队交流时，你会听到很多这样的说法。根据统计，2018年全球约有90％的开发人员在使用敏捷开发。Choerodon猪齿鱼团队也是其中之一。 但是，敏捷并不统一。作为组织工作流程的一般方法，敏捷软件开发设定了共同的价值观和原则，旨在精简开发流程，敏捷有效地响应变化。这些价值观和原则可以在敏捷宣言中找到，当中就提供了一些建立开发流程的建议。 在实际应用中，几种软件开发框架已经体现了这些敏捷原则。其中Kanban 和 Scrum是最受欢迎和经常使用的。这两种方法都有一个共同的目标，即创建一个有效的工作流程。今天这篇文将围绕他们之间的差异进行讨论。 Scrum和Kanban的基础知识 在深入研究Scrum和Kanban之间的差异之前，先看一下两个框架的主要概念，以便之后可以更轻松地进行Kanban与Scrum的比较。虽然它们都旨在建立一个自组织团队的流动，但是有些方法不同。 ▌Scrum是什么？ Scrum的名字来自橄榄球术语，表示“争球”的动作。在软件开发中，Scrum是指采取组织团队合作的方法，以便更高效地开发复杂的软件产品。 Scrum基于开发团队在开始时不知道项目的结果这个假设，他们会随着工作的进展不断学习和适应。Scrum旨在通过每次迭代开始时重置优先级来简化这种适应，这在Scrum术语中称为“Sprint”。 在这里

本文是 Choerodon 猪齿鱼敏捷管理系列文章的第三篇。在上一篇文章《 Choerodon猪齿鱼敏捷管理实践（二）——冲刺管理 》中介绍了在敏捷开发中如何使用Choerodon猪齿鱼来管理需求和冲刺。当进行敏捷开发时，与之相关的Scrum会议穿插在整个迭代开发中，本篇将重点介绍Choerodon猪齿鱼敏捷管理对各种会议是如何进行管理支持的。 文章主要内容： Choerodon的需求和冲刺管理回顾 Choerodon对敏捷各类会议的管理支持 计划会 每日站会 评审会 回顾会 总结 Choerodon的需求和冲刺管理回顾 Choerodon敏捷管理中，我们使用用户故事地图和待办事项进行需求和冲刺管理。在敏捷开发实践中，整理需求和规划冲刺是开发中的重要阶段，通过规划管理可以使开发达到以下目标： 可视化管理团队 明确开发需求优先级 明确各个任务项 可视化任务进展情况 明确需求和冲刺管理的目标后，我们会有四个敏捷会议贯穿整个开发过程，需要开发团队的每个成员参与其中，此时也可以使用Choerodon敏捷管理进行会议的管理支持来达到团队的开发目标。 Choerodon对敏捷各类会议的管理支持 标准的敏捷流程包含了四个会议，即计划会、每日站会、评审会和回顾会。我们在实际开发中会结合Choerodon猪齿鱼平台来管理支持团队中的敏捷会议。 计划会 在每个Sprint进入开发之前

知识管理是Choerodon猪齿鱼的一个重要功能，支持在线自定义文档编辑、成员协助共享等功能，帮助团队集中管理创意、需求和设计。本文将会和大家聊一聊知识管理对敏捷团队的重要性，介绍Choerodon选用XWiki作为开发基础的原因，以及开发团队如何设计Choerodon知识管理，最后会简单介绍一下Choerodon知识管理的一些主要功能和特色。 敏捷团队的知识管理 对于软件开发团队来说，每个成员都是知识工作者，知识工作者需要具备一个很重要的能力——知识管理能力。知识是软件行业的灵魂和生存之本，然而很多时候大家都忽略或轻视了团队知识管理的重要性，所以Choerodon希望能够为团队提供一个便捷高效的知识管理方式。 Choerodon猪齿鱼知识管理是为了解决敏捷团队在快速迭代的开发过程中可能忽视的知识沉淀、文档管理和团队协作等问题而诞生的。 印第安人在赶了3天路之后，会停下来小憩一天，因为他们要等待自己的灵魂跟上来。敏捷开发过程也是如此，在经历一个迭代或者冲刺之后，也需要做一些休整，那就是敏捷回顾。每次回顾时，团队成员需要归纳总结开发过程中积累下来的各种问题或经验，并将这些知识记录在可共享的wiki上，这样既便于团队成员互相学习，也利于以后需要时快速查阅。 为什么基于XWiki开发Choerodon知识管理 现在常见到的wiki有很多，开源免费的如 MediaWiki、DokuWiki

Choerodon猪齿鱼知识管理是一种内容管理工具，具有创建、编辑、导航、链接、搜索等功能。它为企业、IT团队提供方便的项目协作平台和强大的项目内容管理平台，集中式管理产品相关内容等，例如需求收集、架构设计、功能设计、开发规范、命名规范、会议记录、计划安排等。 在0.17版本中，猪齿鱼上线了新的知识管理，作为项目团队内容管理功能，并在0.18做了升级和功能增强，而原有的承载知识管理功能的Wiki管理将在0.19版本正式下线。 那么，这个新的知识管理和之前的“知识管理（Wiki管理）”有何不同？ 新老知识管理有何区别？ 猪齿鱼早期的知识管理——“Wiki管理”是团队基于开源产品XWiki所开发。XWiki是一个由Java编写的基于LGPL协议发布的开源wiki和应用平台，基本涵盖了在知识、文档管理等方面所需的各种大小功能。但随着产品的不断演进，XWiki官方团队减少对产品的投入，大大降低了迭代以及运维的效率。 而0.18版本中使用的知识管理则由猪齿鱼团队自行开发，内置于猪齿鱼平台，不再需要跳转至Wiki空间，保留了文档编辑、分享、管理等基本功能，整体上更加轻量。 为什么要重新开发一个新的知识管理服务？ 随着更多新用户的增加以及数据的不断积累，XWiki已经无法满足用户在体验和操作上的更高需求，根据社区成员和用户的反馈，猪齿鱼进行了商议和选型，经过1个迭代的周期推出了新的知识管理。

本文档将介绍如何将现有的应用迁移到Choerodon猪齿鱼平台。主要分为以下几个部分： 应用环境搭建 数据库迁移 应用迁移 使用Choerodon猪齿鱼 下面将以资产云平台迁移到Choerodon猪齿鱼为例，详细地介绍如何将一个一般应用迁移到Choerodon中，并使用Choerodon作为开发、发布和部署的支撑平台。 注：本手册使用的Choerodon猪齿鱼版本是 0.9版本 。 另外，在根据本文档执行迁移之前，请务必学习Docker、Kubernetes、Helm、Gitlab-CI等知识，尽量熟练掌握。 应用系统环境搭建 Choerodon猪齿鱼平台是一个PaaS平台，其本身不提供应用系统的运行环境，用户需要自主安装Kubernetes集群，一般来说一个应用系统需要有开发环境、测试环境和正式环境（如下图所示），每一个环境都是一个独立的Kubernetes集群。当然用户也可以根据具体的需求来调整，例如开发环境和测试环境共用一套Kubernetes集群。 所以，利用Choerodon猪齿鱼PaaS能力的第一项任务就是搭建应用系统的运行环境。 准备服务器 Choerodon猪齿鱼支持本地化部署，也支持公用云部署。Kubernetes集群的硬件要求与应用系统的要求一致，当然考虑到应用系统已经完全容器化，所以用户可以根据自身需求动态定制Kubernetes集群的规模