微服务设计模式

  categories:资料  author:

这里说的是为服务设计模式,  题目很大, 也不知道能否说好, 先简单的有一下, 有问题的地方我在修改!

双十一刚刚过去, 我们也沾上一点双十一的热气,现在电商系统可谓五花八门,形形色色,表面看就是一个卖东西, 其实地下包括了商品展示、商品管理、商品库存、商家、支付、保险、运输等等非常多的环节。 有的商品是房子,有的商品是家电等等! 他们的购买流程是一样的吗?估计买房子的流程同其他的流程完全不同了!

一. 传统的单一服务应用

1. 传统单一服务系统应用场景

传统的应用系统通常如下图:

用户通过互联网访问应用系统, 然后在应用系统内部调用数据库系统。

通常情况下各个功能模块都集中在应用系统中,这样开发简单,维护方便,在业务量不大的情况下还是比较实用的。

但是到了双十一这个超级压力大的情况下, 传统的系统就有些问题了,如上图中小绿负责的模块包括了一个慢查询语句,这样系统的整个资源都被占满了, 造成其他相关模块无辜的被拖累。 具体如下图

上图中可以清楚看到在传统的业务系统中经常将一系列耦合比较小或者相关性不大的模块合并到一起进行开发、测试、部署、维护等等, 这样在业务量不大时还看不出问题, 但当公司业务发展, 系统访问量增大后, 就有了上图的问题。

理论一点说法:传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。尽管也是遵循模块化开发,但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR,部署在Tomcat或者Jetty上。

2. 这种单体应用比较适合于小项目,优点是:

  • 开发简单直接,集中式管理
  • 基本不会重复开发
  • 功能都在本地,没有分布式的管理开销和调用开销

3. 单体应用的缺点

当然它的缺点也十分明显,特别对于互联网公司来说:

缺点一:项目过于臃肿

当大大小小的功能模块都集中在同一项目的时候,整个项目必然会变得臃肿,让开发者难以维护。

缺点二:资源无法隔离

就像刚刚小灰的经历一样,整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源,一旦某个功能模块对资源使用不当,整个系统都会被拖垮。… 阅读全文

JSON入门

  categories:资料  author:

什么是json?为什么用json?

json是一种采用文本方式表示数据的方法!  请注意这里最重要的就是这个  文本方式表示数据的  文本是及其重要的!!

原因是 文本是  计算机里面非常普遍 非常普遍的, 在说一下, 非常普遍的方式, 普遍到, 你随便找个计算机就可以有文本查看,和编辑的工具, 这样 就非常方便的  查看,编辑 json的文本了, 便于调试、开发、修改等等!

及其重要的, 无论您水平多高, 程序都可能有bug的, 因此若是一个程序出了问题是  读取或者操作的数据有问题, 还是程序问题?   这样json的普通程序都可以查看的  特点为我们调试程序带来了福音!!

另外json除了普通外, 还有强大, 从文本数据, 二进制数据,流量流, 图片,声音等等, 只要你能搞到内存中, 就可以用json来表示, 你看人家支持byte[] 数据的, 因此只要你能变为byte[] 就能变为json,并且是文本!!

好了, 下面是网络上介绍json的两个资料整理到这里了, 大家有空慢慢看吧。… 阅读全文

一篇文章快速理解微服务架构

  categories:资料  author:

什么是微服务

首先微服务并没有一个官方的定义,想要直接描述微服务比较困难,我们可以通过对比传统WEB应用,来理解什么是微服务。
1.jpg

传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图如下:

尽管也是遵循模块化开发,但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR,部署在Tomcat或者Jetty上。

这种单体应用比较适合于小项目,优点是:

  • 开发简单直接,集中式管理
  • 基本不会重复开发
  • 功能都在本地,没有分布式的管理开销和调用开销

当然它的缺点也十分明显,特别对于互联网公司来说:

  • 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断
  • 代码维护难:代码功能耦合在一起,新人不知道何从下手
  • 部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长
  • 稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉
  • 扩展性不够:无法满足高并发情况下的业务需求

所以,现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用,而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能,比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。** 如果你想和更多微服务技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态**。

比如,前面描述的系统可被分解为:

2.jpg

每个业务逻辑都被分解为一个微服务,微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下,这些客户端并不能直接访问后台微服务,而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

微服务架构的优点

微服务架构有很多重要的优点。首先,它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变,但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平,而这通过单体代码库很难实现。因此,微服务开发的速度要快很多,更容易理解和维护。

其次,这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约,开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务,由于服务相对较小,所以这并不会对整体应用造成太大影响。

第三,微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI/CD成为可能。

最后,微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务,在EC2内存优化实例上部署内存数据库服务。

微服务架构的缺点和挑战

实际上并不存在silver bullets,微服务架构也会给我们带来新的问题和挑战。其中一个就和它的名字类似,微服务强调了服务大小,但实际上这并没有一个统一的标准。业务逻辑应该按照什么规则划分为微服务,这本身就是一个经验工程。有些开发者主张10-100行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的,但要记住,微服务是达到目的的手段,而不是目标。微服务的目标是充分分解应用程序,以促进敏捷开发和持续集成部署。

微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信,而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。

微服务的另一个挑战是分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单,因为单体应用往往只存在一个数据库。但在微服务架构下,不同服务可能拥有不同的数据库。CAP原理的约束,使得我们不得不放弃传统的强一致性,而转而追求最终一致性,这个对开发人员来说是一个挑战。

微服务架构对测试也带来了很大的挑战。传统的单体WEB应用只需测试单一的REST API即可,而对微服务进行测试,需要启动它依赖的所有其他服务。这种复杂性不可低估。

微服务的另一大挑战是跨多个服务的更改。比如在传统单体应用中,若有A、B、C三个服务需要更改,A依赖B,B依赖C。我们只需更改相应的模块,然后一次性部署即可。但是在微服务架构中,我们需要仔细规划和协调每个服务的变更部署。我们需要先更新C,然后更新B,最后更新A。

部署基于微服务的应用也要复杂得多。单体应用可以简单的部署在一组相同的服务器上,然后前端使用负载均衡即可。每个应用都有相同的基础服务地址,例如数据库和消息队列。而微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外,我们还需要服务发现机制,以便服务可以发现与其通信的其他服务的地址。因此,成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。

以上问题和挑战可大体概括为:

  • API Gateway
  • 服务间调用
  • 服务发现
阅读全文

漫画:什么是微服务

  categories:资料  author:

单体架构的痛点

缺点一:项目过于臃肿

当大大小小的功能模块都集中在同一项目的时候,整个项目必然会变得臃肿,让开发者难以维护。

缺点二:资源无法隔离

就像刚刚小灰的经历一样,整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源,一旦某个功能模块对资源使用不当,整个系统都会被拖垮。

缺点三:无法灵活扩展

当系统的访问量越来越大的时候,单体系统固然可以进行水平扩展,部署在多台机器上组成集群:

但是这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块,希望只针对支付模块做水平扩展,这一点在单体系统是做不到的。

什么是微服务?

微服务(Microservice Architecture)是近几年流行的一种架构思想,关于它的概念很难一言以蔽之。

究竟什么是微服务呢?我们在此引用 ThoughtWorks 公司的首席科学家 Martin Fowler 的一段话:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in

阅读全文

Android在子线程中更新UI的方法汇总(共七种)

  categories:资料  author:

Android在子线程中更新UI的方法汇总(共七种)

1、常规写法:new Handler()的handleMessage()和handler.sendMessage(msg)

    Handler handler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    };

   new Thread(new Runnable() {
            @Override
            public void run() {
                Message msg = Message.obtain();
                msg.what = 1000;
                msg.arg1 = 10;
                handler.sendMessage(msg);
            }
        }).start();
阅读全文

android约束布局ConstraintLayout

  categories:资料  author:

相对于 RelativeLayout来说性能更好,布局上也更加灵活。在最新的Google Android开发文档中是推荐使用ConstraintLayout的,下面来看看具体用法。

0x00 相对位置(Relative positioning)

这个比较简单,看图解释,假设控件B要放在控件A的右侧,可以使用 layout_constraintLeft_toRightOf属性。

1
2
3
<Button android:id="@+id/buttonA" ... />
<Button android:id="@+id/buttonB" ...
     app:layout_constraintLeft_toRightOf="@+id/buttonA" />

看图2可以了解控件约束属性代表的含义。

类似相对位置的约束属性有:

  • layout_constraintLeft_toLeftOf
  • layout_constraintLeft_toRightOf
  • layout_constraintRight_toLeftOf
  • layout_constraintRight_toRightOf
  • layout_constraintTop_toTopOf
  • layout_constraintTop_toBottomOf
  • layout_constraintBottom_toTopOf
  • layout_constraintBottom_toBottomOf
  • layout_constraintBaseline_toBaselineOf
  • layout_constraintStart_toEndOf
  • layout_constraintStart_toStartOf
  • layout_constraintEnd_toStartOf
阅读全文

Android应用进程防杀指南

  categories:资料  author:

项目测试的时候发现,按home键回到桌面,再用360清理内存,软件被结束,再次进入的时候报错,看了下log,以为是有的地方没有控制好,但是又不知道360结束的是什么(这个现在还没弄明白)。使用小米系统的进程管理优化内存就不报错。

后来想到用Service防止软件被kill掉,查了下资料,发现google 管方就有,ForegroundService 前台服务,让服务一直以前台任务的方式运行,可以在service 的oncreate来实现前台服务, 通过这个方法必须发送一个通知栏,让用户知道服务在运行。
Notification notification = new Notification(R.drawable.icon, “服务开启”, System.currentTimeMillis());
notification.flags|= Notification.FLAG_NO_CLEAR;
notification.flags=Notification.FLAG_ONGOING_EVENT;
Intent notificationIntent = new Intent(this, MainActivity.class);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, notificationIntent, 0);
notification.setLatestEventInfo(this, “service”, “防止服务被任务管理器所杀”, pendingIntent);
startForeground(ONGOING_NOTIFICATION, notification);

这样就能保持service 运行,可是通知栏不能清除 ,一清除就会被kill。
后来一次 做自定义Notification的时候,通知栏没有显示通知,查看后发现

阅读全文

Android Studio常用配置以及快捷键

  categories:资料  author:

概述

整理Android Studio的常用配置和快捷键。

常用配置

显示行号

临时显示

永久显示

File——Settings——Editor——General——Appearance——勾选 Show line numbers

切换主题

File——Settings——Appearance & Behavior——Appearance——Theme

Darcula:经典的黑色背景主题
IntelliJ:白色背景,经典但不花哨
Windows

更改菜单栏的字体

File——Settings——Appearance & Behavior——Appearance

勾选 Override default fonts by (not recommended) ,选择字体、设置大小。

效果:

编码区域字体设置

 File——Settings——Editor——Colors & Fonts——Font

在Android Studio2.2.2版本中,默认系统显示的 Scheme 为 Defualt

阅读全文



快乐成长 每天进步一点点      京ICP备18032580号-1