Happy Coding, Happy Life

微服务实战(5) - HAL 101

| Comments

[如需转载,请联系本人]

过去的几个月,我作为独立咨询师,为多个传统企业提供了微服务架构的培训、咨询以及交付工作。在这些企业中,大部分的开发者对微服务的理解,以“银弹观念”为主。实际上,传统企业在过去多年的业务积累中,由于组织架构、业务发展和市场竞争等综合因素,技术体系相对封闭,缺乏快速交付的理念。因此,微服务的出现,加之社区的热捧,导致这种现象出现也是比较能理解的。

经过2015年的快速普及,微服务的优势被越来越多的传统组织和企业所认可,但由于架构相关的知识本身比较抽象,虽然各大会议上有很多互联网公司的案例分享,但开发者似乎依然很难全面了解微服务架构。

所以,希望通过本系列的文章,以一个模拟的案例为背景,以持续交付和DevOps为主线,帮助初学者理解微服务架构,并能通过动手实验,了解相关的实践以及方法论。

精彩课程已经出炉,请移步这里

微服务实战(4) - Spring Cloud 101

| Comments

[如需转载,请联系本人]

过去的几个月,我作为独立咨询师,为多个传统企业提供了微服务架构的培训、咨询以及交付工作。在这些企业中,大部分的开发者对微服务的理解,以“银弹观念”为主。实际上,传统企业在过去多年的业务积累中,由于组织架构、业务发展和市场竞争等综合因素,技术体系相对封闭,缺乏快速交付的理念。因此,微服务的出现,加之社区的热捧,导致这种现象出现也是比较能理解的。

经过2015年的快速普及,微服务的优势被越来越多的传统组织和企业所认可,但由于架构相关的知识本身比较抽象,虽然各大会议上有很多互联网公司的案例分享,但开发者似乎依然很难全面了解微服务架构。

所以,希望通过本系列的文章,以一个模拟的案例为背景,以持续交付和DevOps为主线,帮助初学者理解微服务架构,并能通过动手实验,了解相关的实践以及方法论。

精彩课程已经出炉,请移步这里

微服务实战(3) - Spring Boot 101

| Comments

[如需转载,请联系本人]

过去的几个月,我作为独立咨询师,为多个传统企业提供了微服务架构的培训、咨询以及交付工作。在这些企业中,大部分的开发者对微服务的理解,以“银弹观念”为主。实际上,传统企业在过去多年的业务积累中,由于组织架构、业务发展和市场竞争等综合因素,技术体系相对封闭,缺乏快速交付的理念。因此,微服务的出现,加之社区的热捧,导致这种现象出现也是比较能理解的。

经过2015年的快速普及,微服务的优势被越来越多的传统组织和企业所认可,但由于架构相关的知识本身比较抽象,虽然各大会议上有很多互联网公司的案例分享,但开发者似乎依然很难全面了解微服务架构。

所以,希望通过本系列的文章,以一个模拟的案例为背景,以持续交付和DevOps为主线,帮助初学者理解微服务架构,并能通过动手实验,了解相关的实践以及方法论。

精彩课程已经出炉,请移步这里

微服务实战(2) - 目标系统

| Comments

[如需转载,请联系本人]

过去的几个月,我作为独立咨询师,为多个传统企业提供了微服务架构的培训、咨询以及交付工作。在这些企业中,大部分的开发者对微服务的理解,以“银弹观念”为主。实际上,传统企业在过去多年的业务积累中,由于组织架构、业务发展和市场竞争等综合因素,技术体系相对封闭,缺乏快速交付的理念。因此,微服务的出现,加之社区的热捧,导致这种现象出现也是比较能理解的。

经过2015年的快速普及,微服务的优势被越来越多的传统组织和企业所认可,但由于架构相关的知识本身比较抽象,虽然各大会议上有很多互联网公司的案例分享,但开发者似乎依然很难全面了解微服务架构。

所以,希望通过本系列的文章,以一个模拟的案例为背景,以持续交付和DevOps为主线,帮助初学者理解微服务架构,并能通过动手实验,了解相关的实践以及方法论。

精彩课程已经出炉,请移步这里

微服务实战(1) - 内容大纲

| Comments

[如需转载,请联系本人]

过去的几个月,我作为独立咨询师,为多个传统企业提供了微服务架构的培训、咨询以及交付工作。在这些企业中,大部分的开发者对微服务的理解,以“银弹观念”为主。实际上,传统企业在过去多年的业务积累中,由于组织架构、业务发展和市场竞争等综合因素,技术体系相对封闭,缺乏快速交付的理念。因此,微服务的出现,加之社区的热捧,导致这种现象出现也是比较能理解的。

经过2015年的快速普及,微服务的优势被越来越多的传统组织和企业所认可,但由于架构相关的知识本身比较抽象,虽然各大会议上有很多互联网公司的案例分享,但开发者似乎依然很难全面了解微服务架构。

所以,希望通过本系列的文章,以一个模拟的案例为背景,以持续交付和DevOps为主线,帮助初学者理解微服务架构,并能通过动手实验,了解相关的实践以及方法论。

精彩课程已经出炉,请移步这里

微服务实战(0) - 聊聊开篇

| Comments

[如需转载,请联系本人]

过去的几个月,我作为独立咨询师,为多个传统企业提供了微服务架构的培训、咨询以及交付工作。在这些企业中,大部分的开发者对微服务的理解,以“银弹观念”为主。实际上,传统企业在过去多年的业务积累中,由于组织架构、业务发展和市场竞争等综合因素,技术体系相对封闭,缺乏快速交付的理念。因此,微服务的出现,加之社区的热捧,导致这种现象出现也是比较能理解的。

经过2015年的快速普及,微服务的优势被越来越多的传统组织和企业所认可,但由于架构相关的知识本身比较抽象,虽然各大会议上有很多互联网公司的案例分享,但开发者似乎依然很难全面了解微服务架构。

所以,希望通过本系列的文章,以一个模拟的案例为背景,以持续交付和DevOps为主线,帮助初学者理解微服务架构,并能通过动手实验,了解相关的实践以及方法论。

精彩课程已经出炉,请移步这里

解析微服务架构

| Comments

过去的1年多,一直在助力澳洲最大的房地产互联网门户,研究并使用微服务架构改造其复杂的遗留系统。鉴于此,准备开个系列,讲讲我个人眼中的微服务是神马样的,它的概念,优缺点,为什么我们要使用它,以及在使用微服务的实践过程中,从开发、测试、部署、运维等几个方面相比以前方式有什么不同;同时,分享一下我们在微服务实践过程中的经验和踩过的那些坑。

解析微服务架构(四)

| Comments

[请勿转载]

微服务架构的优缺点

将单块架构应用分解为一系列相对独立的微服务,其中每个服务都运行在自己的进程中,并且通过轻量级的机制实现彼此间的通信,这通常是HTTP资源的微服务。这些服务是围绕着业务功能构建的,并且可以通过完全自动化的部署机制进行独立部署。这些服务的集中式管理做到了最小化,每一种服务都可以通过不同的编程语言进行编写,并且可以使用不同的数据存储技术。

解析微服务架构(三)

| Comments

[请勿转载]

微服务架构的核心特征

什么是核心特征,就是当我们谈论同一件事情的时候,那些不同的人们所关注的相同的部分。从业界的讨论来看,微服务通 常有如下几个显著特征:

  • 服务与组件

一直以来,我们都比较提倡使用组件(Component)的方式,模块化应用系统。它类似生活中的汽车,由不同的零件组成,每个零件都是可以独立替换的。因此,这类通常都有很好的灵活性和替换性。

在软件领域,我们也将组件定义为应用软件构建中独立的单元,它的最大特点是,对整个应用软件而言,组件能够被容易的替代或者更新。

传统实现组件的方式是采用和应用程序一样的的编程语言,构建独立的共享库(Libaray),从而达到解耦和复用的效果。对于共享库而言,我们知道它是语言相关、平台相关,并且是和应用程序运行在同一个进程中的,因此,任何共享库的变化都意味着整个应用程序也要被更新,并且需要被重新部署。换句话说,如果应用由多个共享库组件组成,那么任何库的变更都将导致整体应用的重新发布。

解析微服务架构(二)

| Comments

[请勿转载]

什么是微服务架构

在上一章中,我们认识了什么是单块架构应用,并分析了随着互联网时代的快速发展,随着市场变化快,用户需求变化快以及用户访问量的增加,单块架构应用的维护成本、人员的培养成本、缺陷修复成本以及技术架构演进的成本和系统扩展成本等都在增加,因此单块架构曾经的优势已逐渐无法适应互联网时代的快速变化,面临着越来越多的挑战。

在本章中,我们来了解到底什么是微服务架构,以及为什么微服务架构能有效解决单块架构在互联网时代所面临的挑战。

概述

微服务架构一词在过去几年里,得到了广泛的讨论和关注。微服务架构提倡通过对特定业务领域的分析与建模,将复杂的、 集中的、耦合度高的应用系统分解成小而专、耦合度低并且高度自治的一组服务。这些服务与服务之间相互协作、相互配合,从而为最终用户或其他系统提供相应的功能。微服务将每个独立的业务逻辑划分出来,运行在它们自己的进程中,然后通过分布式的网络互相通信与协作,从而为终端用户或其他调用者提供灵活的接口。