[转]业务越来越复杂，领域驱动如何在业务开发中落地？
最近一段时间，领域驱动和微服务受到了越来越多的关注。对于互联网从业者来说，业务会变得越来越复杂，这时候就需要一些系统的方法论来指导开发实现，目前业界关注比较多的方法论就是领域驱动。那么，领域驱动如何应用到具体的项目中？在项目过程中需要注意哪些问题？
Category: About Micro Service Architecture
[转]微服务化很难？一文简单理解服务拆分与服务发现
说到微服务，服务拆分是绕不过去的话题，但是微服务不是说拆就能拆的，有很多的前提条件 1. 服务拆分的前提 服务拆分的前提，首先要有一个持续集成的平台，使得服务在拆分的过程中，保持功能的一致性。 这种一致性不能通过人的经验来，而是需要经过大量的回归测试集，并且持续的拆分，持续的演进，持续的集成，从而保证系统时刻处于可以验证交付的状态。 而非闭门拆分一段时间，最终谁也不知道功能最终究竟有没有 Bug，因而需要另外一个月的时间专门修改 Bug。
[转]单点登录原理与实现
1. 一、单系统登录机制 1-1. 1、http无状态协议 web应用采用browser/server架构，http作为通信协议。http是无状态协议，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联，这个过程用下图说明，三次请求/响应对之间没有任何联系
[转]阿里巴巴微服务与配置中心技术实践之道
在面向分布式的微服务系统中，如何通过更高效的配置管理方式，帮助微服务系统架构持续“无痛”的演进，动态调整和控制系统的运行时飞行姿态，值得我们好好的在配置管理上重新思考和设计。别让您的微服务被配置管理“绊”了一跤！ 本文是阿里巴巴高级技术专家 @坤宇在 2017 年 QCon 微服务专题演讲中关于微服务与配置中心的演讲实录的文字版，演讲视频可以参见： http://www.infoq.com/cn/presentations/micro-service-and-configuration-center?spm=a2c4e.11153940.blogcont332358.36.30772099lWiw8H 阿里巴巴集团早在 2007 年进行从 IOE 集中式应用架构升级为互联网分布式服务化架构的时候，就意识到在分布式环境中，传统的分散式的、基于配置文件的、应用自包含的配置管理方式将面临重大挑战，亟需设计匹配新架构的新的配置管理解决方案，解决诸如分布式服务治理，数据源容灾切换，异地多活，预案，限流规则等场景下的配置变更以及热生效问题，这直接诞生了今天阿里集团内部被广泛使用的配置中心 ACM(Diamond)，而这也是目前世界上最大的配置中心，存储了超过百万的生产配置，在集团内部支持了包括淘宝、天猫、菜鸟、阿里云、高德等全网几乎阿里所有的应用，每天产生近 10 亿次的配置变更推送。
[转]微服务架构技术栈选型手册
1. 一、前言 2014 年可以认为是微服务 1.0 的元年，当年有几个标志性事件，一是 Martin Fowler 在其博客上发表了”Microservices”一文，正式提出微服务架构风格；二是 Netflix 微服务架构经过多年大规模生产验证，最终抽象落地形成一整套开源的微服务基础组件，统称 NetflixOSS，Netflix 的成功经验开始被业界认可并推崇；三是 Pivotal 将 NetflixOSS 开源微服务组件集成到其 Spring 体系，推出 Spring Cloud 微服务开发技术栈。 一晃三年过去，微服务技术生态又发生了巨大变化，容器，PaaS，Cloud Native，gRPC，ServiceMesh，Serverless 等新技术新理念你方唱罢我登场，不知不觉我们又来到了微服务 2.0 时代。 基于近年在微服务基础架构方面的实战经验和平时的学习积累，我想总结并提出一些构建微服务 2.0 技术栈的选型思路，供各位在一线实战的架构师、工程师参考借鉴。对于一些暂时还没有成熟开源产品的微服务支撑模块，我也会给出一些定制自研的设计思路。 2. 二、选型准则 对于技术选型，我个人有很多标准，其中下面三项是最重要的： 2-1....
[转]API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd
1. 前几天拜读了 OpsGenie 公司（一家致力于 Dev & Ops 的公司）的资深工程师 Turgay Çelik 博士写的一篇文章（链接在文末），文中介绍了他们最初也是采用 Nginx 作为单体应用的网关，后来接触到微服务架构后开始逐渐采用了其他组件。 我对于所做的工作或者感兴趣的技术，喜欢刨根问底，所以当读一篇文章时发现没有看到我想要看到的设计思想，我就会四处搜集资料，此外这篇文章涉及了我正在捣鼓的 Spring Cloud，所以我就决定写一篇文章，争取能从设计思路上解释为什么会有这样的性能差异。
[转]运维能力是微服务架构的先决条件
今天我们来聊聊微服务架构模式下的一个核心概念：应用。 我会从这几个方面来讲：应用的起源、应用模型和应用关系模型建模以及为什么要这样做。最终希望，在微服务的架构模式下，我们的运维视角一定转到应用这个核心概念上来，一切要从应用的角度来分析和看待问题。
[转]5年时间服务器从0到200，一个创业公司的架构野蛮生长史
贝聊成立于 2013 年，是中国幼儿园家长工作平台，致力于通过互联网产品及定制化解决方案，帮助幼儿园解决展示、通知、沟通等家长工作中的痛点，促进家园关系和谐。贝聊是威创股份（A 股幼教第一股）、清华启迪、网易联手投资的唯一品牌。在短短几年内，用户规模迅速达到千万级别，每年 DAU 均呈倍数级增长。 面对如此快速的发展，原有的技术架构很难支撑越来越复杂的业务场景，在系统可用性以及稳定性方面，都给贝聊技术团队带来了很大的压力。因此，如何针对当前需求，选择合适的技术架构，保证架构平滑演进，值得我们深入思考。
[转]单点登录怎么实现
一、单点登录简介 假设一个场景：公司内部有财务、OA、订单服务等各类相互独立的应用系统，员工张三对这些系统有操作权限，如果张三想要登录某个系统进行业务操作，那么他需要输入相应的账号与密码。想象一下，当公司内部有 100 个应用系统，张三是不是要输入 100 次用户名和密码进行登录，然后分别才能进行业务操作呢？显然这是很不好的体验，因此我们需要引入一个这样的机制：张三只要输入一次用户名和密码登录，成功登录后，他就可以访问财务系统、OA 系统、订单服务等系统。这就是单点登录。
[转]如果潜心研究Netflix微服务技术多年，能学到什么？
1. 写在前面 作者近期针对企业数字化和架构转型思考后陆续写了三篇文章，这篇是第三篇，主题专注微服务和 DevOps 支撑技术，以 Netflix 技术栈为例。第一篇称为《企业的组织架构是如何影响技术架构的》[附录 8]，主题是建立背景上下文 (background)。第二篇称为《将你的组织架构旋转 90 度》[附录 9]，主题专注组织架构转型。 为啥前面要花两篇讲组织架构背景和转型？因为微服务和 DevOps 在本质上需要组织架构转型 (Re-org)，组织架构对了，技术架构才能落地下来。如不考虑组织架构，直接切入技术架构（很多架构师的通病），则失败风险巨大。 为啥要以 Netflix 技术为例？因为 Netflix 是业界微服务和 DevOps 组织的楷模，有大规模生产级微服务的成功实践。而且其技术栈大部分开源，模块化抽象好，整个体系是一个样板。相关技术资料也丰富，可以从其公司的 techblog 或者 slideshare 上直接获得。本文是作者多年研究 Netflix 技术资料的总结，可以认为是对 Netflix 微服务技术架构的一次全面系统的反向工程。
![[汇总]AI经验](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-small-empty.png)
