<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[昌明说]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/neocode</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; neocode]]></copyright><item><title><![CDATA[架构设计笔记_07_识别复杂度]]></title><link>https://blog.youkuaiyun.com/neocode/article/details/115662526</link><guid>https://blog.youkuaiyun.com/neocode/article/details/115662526</guid><author>neocode</author><pubDate>Tue, 13 Apr 2021 13:08:25 +0800</pubDate><description><![CDATA[在设计一个高并发系统之前，首先要认识到该系统的复杂度是什么？前文已经说了引起系统复杂度的三高问题，但是当落实到一个具体业务系统上面时，往往是错综复杂的，下面我们从一个案例来详细讲解，这个案例也是我以前遇到的真实案例。


数千万用户级别的跑步APP，5000万跑步用户，早晚高峰期，使用人数较多，用户可以关注其他跑友，读取最新关注好友的动态。跑步完成后记录会自动上传至服务器，并形成一条动态。用户可以发动态消息，包括文字或者图片。


每到早晨和晚上，系统无法处理大量数据请求，数据同步出错，数据库连接池耗尽，数]]></description><category></category></item><item><title><![CDATA[架构设计笔记_06_高扩展问题]]></title><link>https://blog.youkuaiyun.com/neocode/article/details/115662502</link><guid>https://blog.youkuaiyun.com/neocode/article/details/115662502</guid><author>neocode</author><pubDate>Tue, 13 Apr 2021 13:07:44 +0800</pubDate><description><![CDATA[系统复杂度的另一个原因是高扩展需求引起的。电商秒杀，明星出轨，大量突发性事件导致互联网请求集中爆发，给平台造成大量高并发请求，这时候如果临时修改架构根本来不及，这就要求我们的平台可以通过扩展服务来应对。通过增加机器来实现服务性能的线性增长，等这波流量过去之后，就下线这些机器以节约成本。

系统的扩展性，通过若干种手段可以实现，从两个场景来进行设计。

代码层面
基本的软件设计模式，即开闭原则，保证对扩展开放，对修改闭合。业务层和数据访问层，控制层和业务层都是通过接口来实现的，这里的接口就是一种扩展机制，保证]]></description><category></category></item><item><title><![CDATA[架构设计笔记_05_高可用问题]]></title><link>https://blog.youkuaiyun.com/neocode/article/details/115662404</link><guid>https://blog.youkuaiyun.com/neocode/article/details/115662404</guid><author>neocode</author><pubDate>Tue, 13 Apr 2021 13:06:04 +0800</pubDate><description><![CDATA[系统复杂度的另一个原因是高可用性，即无间断的提供服务。业内一半用几个9来表达服务的可用程度，即如下公式：

服务年度可用性=(服务年度可用时间/年度总时间) x 100%

知名大型网站要达到99.99%（俗称4个9），也是很难的，支付宝还会被挖断光缆，百度DNS解析也会出现问题呢！

任何软件和硬件都会出现问题，磁盘会坏，软件有bug，按理说每50行代码就有可能产生一个bug，windows系统bug是修改不完的 ，所以一直在打patch啊！如何实现系统的高可用，通过冗余，就是增加机器的方式，这里增加机器]]></description><category></category></item><item><title><![CDATA[架构设计笔记_04_高性能问题]]></title><link>https://blog.youkuaiyun.com/neocode/article/details/115662351</link><guid>https://blog.youkuaiyun.com/neocode/article/details/115662351</guid><author>neocode</author><pubDate>Tue, 13 Apr 2021 13:04:13 +0800</pubDate><description><![CDATA[系统的复杂程度是由很多原因引起的，高性能问题是其中之一，那高性能问题又是什么引起的呢？严格意义上说高性能不是问题，而是一个需求，随着互联网时代到来，特别是移动互联网，人们随时随地都在产生数据，对于单机服务来说已经无法承受大量的计算和网络请求了，所以提出了对于高性能服务的需求。在两种场景下，即单机和服务器集群，都有提高性能的解决方案，下面聊聊这两种方式对于我们软件而言带来的复杂性。

单机服务
单机提供服务时，如果想提高性能，可以通过增加内存，增加核数，改用SSD，增加网卡吞吐量，这是通过改进硬件的形式提高性]]></description><category></category></item><item><title><![CDATA[架构设计笔记_03_设计原则和方法论]]></title><link>https://blog.youkuaiyun.com/neocode/article/details/115662284</link><guid>https://blog.youkuaiyun.com/neocode/article/details/115662284</guid><author>neocode</author><pubDate>Tue, 13 Apr 2021 13:02:23 +0800</pubDate><description><![CDATA[上一讲解释了几个名词，也就是架构和组件模块以及框架平台等之间的关系，这节我们直接进入正题，架构设计的三个原则，先给结论。

合适原则
是用mysql还是oracle，要看你的业务场景，比如电信的系统，原有系统很多都在oracle上存储数据，你不可能一下子全部换掉，但是电信业务的一个周边系统，全新的就完全可以用mysql；是用react还是vue，或者jsp，看你团队的技术体系，后期维护成本，业界好的不一定适合；是用单体系统，还是微服务，看项目成本和交付时间节点，一个简单的管理系统，用户总量上限1000，单体]]></description><category></category></item><item><title><![CDATA[架构设计笔记_02_设计原则和方法论]]></title><link>https://blog.youkuaiyun.com/neocode/article/details/113845141</link><guid>https://blog.youkuaiyun.com/neocode/article/details/113845141</guid><author>neocode</author><pubDate>Thu, 18 Feb 2021 13:19:51 +0800</pubDate><description><![CDATA[其实一个软件系统要不要设计架构，要看实际情况，设计架构的目的是为了解决软件系统的复杂度带来的问题。你在写一个图书管理系统的时候，按照常规的写法即可，没有三高要求，这时候不需要做架构设计，但是当这个图书管理系统管理的是全国所有图书馆时，用户是面向全国用户，那就需要架构设计，因为复杂度完全不同。

在讲设计原则之前，我想先聊一下架构到底是什么？架构和框架有什么关系？系统和子系统有亲戚关系吗？系统和平台那个大？那组件和模块呢？是兄弟吗？


	系统和子系统

	微信是一个系统，而朋友圈是微信这个系统中的一个子系统]]></description><category></category></item><item><title><![CDATA[架构设计笔记_01_概述]]></title><link>https://blog.youkuaiyun.com/neocode/article/details/113844961</link><guid>https://blog.youkuaiyun.com/neocode/article/details/113844961</guid><author>neocode</author><pubDate>Thu, 18 Feb 2021 13:04:03 +0800</pubDate><description><![CDATA[不要被架构两个字吓到，架构师到底要不要讲细节？架构师要不要写代码？其实根本没有结论，就好比php是最好的语言，一个意思。没有对错，只有判断和取舍，根据公司业务，财力和场景不同，权衡利弊而已。小孩子才讲对错！

该系列文章会主要涉及到如下内容：


	架构设计理论原则和方法论
	
	
	三高介绍（高可用高并发高性能）
	
	
	架构设计流程之识别复杂度
	
	
	架构设计流程之备选方案
	
	
	架构设计流程之评估和选择
	
	
	架构设计流程之详细方案设计
	
	
	高性能架构模式
	
	
	高并发架构模式]]></description><category></category></item></channel></rss>