日期: 2021 年 4 月 21 日

iOS NSString字符串按照特定字符分割成数组

2021年4月21日
NSString，数组
iOS NSString字符串按照特定字符分割成数组已关闭评论

NSString *str =@”Rem【ar【k”;
NSArray *array = [str componentsSeparatedByString:@”【”]; //字符串按照【分隔成数组
NSLog(@”array=%@=”,array); //结果是

mac 安装打包工具fastlane

2021年4月21日
IOS打包，fastlane，mac
mac 安装打包工具fastlane已关闭评论

#mark ruby gem工具升级相关
//查看gem版本
gem –version
// 查看vgem 版本
ruby -vgem –version
//ruby版本管理工具更新
gem update –system

//查看ruby版本
ruby -v
// 查看ruby所有版本
rvm list known
// 安装ruby指定版本版本
rvm reinstall ruby-2.6.3
// 安装
sudo gem install fastlane –verbose
gem cleanup
// 定位到项目路径
cd 项目.xcodeproj所在文件夹
//打包打包之前需要先配置

iOS Sign in with Apple 苹果登录带配置步骤代码封装

2021年4月21日
配置代码，授权登录代码封装
iOS Sign in with Apple 苹果登录带配置步骤代码封装已关闭评论

苹果授权登录配置
1.Identifiers 勾选 Sign In with Apple

%title插图%num

2.配置key

%title插图%num

4.key 与 Certificates 关联

%title插图%num

6. 更新Profiles的开发配置文件并下载

7. Xcode 开启 Sign In with Apple

%title插图%num

苹果授权登录代码封装
#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>

NS_ASSUME_NONNULL_BEGIN
typedef NS_ENUM(NSUInteger, AppleLoginType) {
AppleLoginTypeUnknown = 0,
AppleLoginTypeSuccessful,
AppleLoginTypeUserSuccessful,
AppleLoginTypeFailure
};

@interface AppleLogin : UIView

/// Apple登录
/// @param user 选填，已存user可以直接快速验证，没有传nil ，断网可验证。
/// @param view <#view description#>
/// @param rect <#rect description#>
/// @param block <#block description#>
+(instancetype)appLogoinFromUser:(NSString *)user view:(UIView *)view rect:(CGRect)rect block:(void(^)(NSInteger state,NSString *msg,id data))block;

@end

NS_ASSUME_NONNULL_END
#import “AppleLogin.h”
#import <AuthenticationServices/AuthenticationServices.h>

typedef void(^AppleLoginBlock)(NSInteger state,NSString *msg,id data);
@interface AppleLogin ()
<
ASAuthorizationControllerDelegate
,ASAuthorizationControllerPresentationContextProviding
>
@property(nonatomic,strong)NSString *userId;
@property(nonatomic,strong)UIView *view;
@property(nonatomic)CGRect rect;
@property(nonatomic,copy)AppleLoginBlock appleLoginBlock;
@end

@implementation AppleLogin

+(instancetype)appLogoinFromView:(UIView *)superView rect:(CGRect)rect block:(void(^)(NSInteger state,NSString *msg,id data))block
{
AppleLogin * appleLogin = [self appLogoinFromView:superView rect:rect];
appleLogin.appleLoginBlock = block;
return appleLogin;
}

+(instancetype)appLogoinFromUser:(NSString *)user view:(UIView *)view rect:(CGRect)rect block:(void(^)(NSInteger state,NSString *msg,id data))block
{
AppleLogin * appleLogin = [self appLogoinFromView:view rect:rect];
appleLogin.userId = user;
appleLogin.appleLoginBlock = block;
return appleLogin;
}

+(instancetype)appLogoinFromView:(UIView *)superView rect:(CGRect)rect
{
AppleLogin * appleLogin = [[AppleLogin alloc]initWithFrame:rect];
appleLogin.view = superView;
appleLogin.rect = rect;
[appleLogin initUI];
return appleLogin;
}

– (void)initUI
{
if (@available(iOS 13.0, *))
{
ASAuthorizationAppleIDButton *button = [ASAuthorizationAppleIDButton buttonWithType:ASAuthorizationAppleIDButtonTypeSignIn style:ASAuthorizationAppleIDButtonStyleBlack];
button.frame = CGRectMake(0, 0, self.rect.size.width, self.rect.size.height);
button.layer.masksToBounds = YES;
button.layer.cornerRadius = self.frame.size.width/2;
[button addTarget:self action:@selector(signInWithApple) forControlEvents:UIControlEventTouchUpInside];
[self addSubview:button];
[self.view addSubview:self];
}
}

#pragma mark ————————————— 登录按钮点击事件 —————————————
– (void)signInWithApple API_AVAILABLE(ios(13.0))
{
if (@available(iOS 13.0, *))
{
NSLog(@”Apple Login Click”);
//基于用户的Apple ID授权用户，生成用户授权请求的一种机制
ASAuthorizationAppleIDProvider *appleIDProvider = [ASAuthorizationAppleIDProvider new];
if (_userId.length == 0)
{
NSLog(@”授权请求AppleID”);
ASAuthorizationAppleIDRequest *request = appleIDProvider.createRequest;
[request setRequestedScopes:@[ASAuthorizationScopeFullName, ASAuthorizationScopeEmail]];
//由ASAuthorizationAppleIDProvider创建的授权请求管理授权请求的控制器
ASAuthorizationController *controller = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[request]];
//设置授权控制器通知授权请求的成功与失败的代理
controller.delegate = self;
//设置提供展示上下文的代理，在这个上下文中系统可以展示授权界面给用户
controller.presentationContextProvider = self;
//在控制器初始化期间启动授权流
[controller performRequests];
}
else
{
// NSLog(@”快速登录使用授权登录返回的 user “);
//快速登录
[appleIDProvider getCredentialStateForUserID:_userId completion:^(ASAuthorizationAppleIDProviderCredentialState credentialState, NSError * _Nullable error) {

if (credentialState == ASAuthorizationAppleIDProviderCredentialAuthorized)
{
NSMutableDictionary *dic = [NSMutableDictionary dictionary];
if (self.appleLoginBlock)
{
self.appleLoginBlock(AppleLoginTypeUserSuccessful,@”ok”,dic);
}
}
else
{ NSMutableDictionary *dic = [NSMutableDictionary dictionary];
[dic setValue:error.description forKey:@”errorMsg”];
[dic setValue:[NSNumber numberWithInteger:error.code] forKey:@”code”];
if (self.appleLoginBlock)
{
self.appleLoginBlock(AppleLoginTypeFailure,error.description,dic);
}
}
}];
}
}
else
{

}
}

#pragma mark ————————————— 成功回调 —————————————
– (void)authorizationController:(ASAuthorizationController *)controller didCompleteWithAuthorization:(ASAuthorization *)authorization API_AVAILABLE(ios(13.0))
{
// NSLog(@”授权完成:::%@”, authorization.credential);
// NSLog(@”%s”, __FUNCTION__);
// NSLog(@”%@”, controller);
// NSLog(@”%@”, authorization);

if ([authorization.credential isKindOfClass:[ASAuthorizationAppleIDCredential class]])
{
// 用户登录使用ASAuthorizationAppleIDCredential
ASAuthorizationAppleIDCredential *appleIDCredential = authorization.credential;
NSString *user = appleIDCredential.user;
// 使用过授权的，可能获取不到以下三个参数
NSString *familyName = appleIDCredential.fullName.familyName;
NSString *givenName = appleIDCredential.fullName.givenName;
NSString *nickname = appleIDCredential.fullName.nickname;
NSString *email = appleIDCredential.email;
NSString *state = appleIDCredential.state;
NSData *identityToken = appleIDCredential.identityToken;
NSData *authorizationCode = appleIDCredential.authorizationCode;
ASUserDetectionStatus realUserStatus = appleIDCredential.realUserStatus;

// 服务器验证需要使用的参数
NSString *identityTokenStr = [[NSString alloc] initWithData:identityToken encoding:NSUTF8StringEncoding];
NSString *authorizationCodeStr = [[NSString alloc] initWithData:authorizationCode encoding:NSUTF8StringEncoding];
// NSLog(@”%@\n\n%@”, identityTokenStr, authorizationCodeStr);

NSMutableDictionary *dic = [NSMutableDictionary dictionary];
[dic setValue:state forKey:@”state”];
[dic setValue:user forKey:@”user”];
[dic setValue:email forKey:@”email”];
[dic setValue:familyName forKey:@”familyName”];
[dic setValue:givenName forKey:@”givenName”];
[dic setValue:nickname forKey:@”nickname”];
// [dic setValue:appleIDCredential forKey:@”appleIDCredential”];
[dic setValue:authorizationCodeStr forKey:@”authorizationCode”];
[dic setValue:identityTokenStr forKey:@”identityToken”];
// [dic setValue:@(realUserStatus) forKey:@”realUserStatus”];

if (self.appleLoginBlock)
{
self.appleLoginBlock(AppleLoginTypeSuccessful, @”ok”,dic);
}
// 需要使用钥匙串的方式保存用户的唯一信息 Keychain
}
else if ([authorization.credential isKindOfClass:[ASPasswordCredential class]])
{
// 这个获取的是iCloud记录的账号密码，需要输入框支持iOS 12 记录账号密码的新特性，如果不支持，可以忽略
// Sign in using an existing iCloud Keychain credential.
// 用户登录使用现有的密码凭证
ASPasswordCredential *passwordCredential = authorization.credential;
// 密码凭证对象的用户标识用户的唯一标识
NSString *user = passwordCredential.user;
// 密码凭证对象的密码
NSString *password = passwordCredential.password;
NSMutableDictionary *dic = [NSMutableDictionary dictionary];
[dic setValue:user forKey:@”user”];
[dic setValue:password forKey:@”password”];
if (self.appleLoginBlock)
{
self.appleLoginBlock(AppleLoginTypeSuccessful, @”ok”,dic);
}
}
else
{
// NSLog(@”授权信息均不符”);
NSString *errorMsg = @”授权信息不符”;
NSMutableDictionary *dic = [NSMutableDictionary dictionary];
[dic setValue:errorMsg forKey:@”errorMsg”];
if (self.appleLoginBlock)
{
self.appleLoginBlock(AppleLoginTypeFailure,errorMsg,dic);
}
}
}

#pragma mark ————————————— 失败回调 —————————————
– (void)authorizationController:(ASAuthorizationController *)controller didCompleteWithError:(NSError *)error API_AVAILABLE(ios(13.0))
{
NSString *errorMsg = nil;
switch (error.code) {
case ASAuthorizationErrorCanceled:
errorMsg = @”用户取消了授权请求”;
break;
case ASAuthorizationErrorFailed:
errorMsg = @”授权请求失败”;
break;
case ASAuthorizationErrorInvalidResponse:
errorMsg = @”授权请求响应无效”;
break;
case ASAuthorizationErrorNotHandled:
errorMsg = @”未能处理授权请求”;
break;
case ASAuthorizationErrorUnknown:
errorMsg = @”授权请求失败未知原因”;
break;
}
NSMutableDictionary *dic = [NSMutableDictionary dictionary];
[dic setValue:errorMsg forKey:@”errorMsg”];
[dic setValue:[NSNumber numberWithInteger:error.code] forKey:@”code”];
if (self.appleLoginBlock)
{
self.appleLoginBlock(AppleLoginTypeFailure,errorMsg,dic);
}
}

#pragma mark ————————————— 告诉代理应该在哪个window 展示内容给用户 —————————————
– (ASPresentationAnchor)presentationAnchorForAuthorizationController:(ASAuthorizationController *)controller API_AVAILABLE(ios(13.0))
{
return [UIApplication sharedApplication].windows.lastObject;
}

@end
调用
#import “ViewController.h”
#import “AppleLogin.h”
@interface ViewController ()

@end

@implementation ViewController

– (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.

// user在*次苹果验证时传空，如果对user做了存储，传user可以快速验证（简单说就是你验证过的user手机里会存，并且每次返回的user都是不一样的，user正确断网也可以验证）
NSString *user ;
[AppleLogin appLogoinFromUser:user view:self.view rect:CGRectMake(100, 100, 60, 60) block:^(NSInteger state, NSString * _Nonnull msg, id _Nonnull data) {
if (state == AppleLoginTypeSuccessful)
{
NSLog(@”授权成功 %@”,data);
}
else if (state == AppleLoginTypeUserSuccessful)
{
NSLog(@”账号验证成功”);
}
else
{
NSLog(@”验证失败： %@”,msg);
}

}];
}

@end

容器云测试、UAT、生产环境应该采用什么样的部署架构和方式

2021年4月21日
UAT, 容器云测试
容器云测试、UAT、生产环境应该采用什么样的部署架构和方式已关闭评论

一、全容器化部署
目前应该是几乎所有的容器云厂商在容器云交流和PoC时都强调所有组件都容器化。这样实施安装部署相对容易，一键部署、半小时搭建容器云平台。但我们在PoC测试中也发现了一些问题，比如容器资源分配的问题，Kubernetes多集群部署问题，控制节点高可用部署问题，镜像仓库定位和部署问题，中间件和不同的环境部署和定位问题等；也发现容器云平台容器异常，新的容器创建，旧的依然在，导致很多无用的容器占用资源，也带来一些理解上的困难。虽然是平台自身实现的问题，但明显是在设计时一些问题没考虑到。

二、环境管理

全容器化部署的好处是可以快速的构建一致性的环境，这也是实现DevOps的一个重要方面。所以在开发测试环境全容器化部署是没有问题的。因为这些环境需求变化快，传统维护开发测试环境需要花费大量的时间和人力，如果采用容器化方式，可以快速构建一个开发测试环境域，用于完成服务的测试。主要完成功能性方面的测试，对于可能涉及到性能测试，我们建议放到UAT环境来做。UAT和生产环境保持软硬件和部署架构一致。UAT和生产环境容器云基础组件建议部署到虚拟机或物理机上，比如集中日志、监控、服务注册发现、服务网关等组件。这样部署的目的一方面是为了更好的利用容器云的轻量化特性，另一方面也是基于安全、运维管理等考虑。

我们也一直说要用简单的方式解决复杂的问题，基于容器云基础设施，我们希望建设企业级服务中台，一家企业只需要维护一套日志系统，一套监控系统，没必要每次都重复建设。这些组件相对固定，并不需要经常改变，而且数据需要保证的安全。通常集中日志系统、监控系统等都需要集群化部署，不是一台机器一个实例能满足需求的。所以在开发测试环境是为了利用容器的快速构建特性，在UAT、生产环境则要保持稳定、安全。采用容器云在环境管理环境部署方面可以有所差别。

各个环境保持独立而又通过镜像仓库联系起来，镜像是联系各个环境的标准交付物。

三、镜像仓库

镜像仓库在容器云平台如何定位？在DevOps中起什么样的价值？这是我们考虑采用容器云平台过程中也一直考虑的问题。以前的讨论中我们提到过，考虑把镜像仓库作为开发测试和生产之间的媒介，开发测试都止于镜像仓库，生产起于镜像仓库。镜像作为标准交付物，在各个环境间传递，镜像仓库通过镜像的安全检查等机制保证镜像安全。也就是DevOps持续集成止于镜像仓库，镜像仓库是部署运营的起点。

镜像仓库要不要部署于容器？其实这个在我们看来不是很重要。首先镜像仓库是基础组件，不会经常需要更改变化，所以其实更适合稳定的部署。另外公共镜像和私有镜像会需要很多的磁盘空间，IO能力会成为一个因素。镜像仓库可以作为镜像的分发中心，也就是我们所说的各环境之间的媒介，或者不同集群之间的媒介。从这个角度来说，镜像仓库可以作为一个独立的部分，只是为容器云平台提供镜像分发服务和镜像管理服务。它可以独立部署，不依赖于容器云平台。物理机或虚拟机部署或许更合适一点，当然，部署于容器也不是不可以。

镜像仓库高可用部署是需要考虑的，这也是很多容器云厂商宣传的一个重要的功能点。如果有充足的资源，我们还是建议镜像仓库部署高可用，毕竟这样可以多一份保障，减少一些意外，但高可用节点不是越多越好，通常主备节点就可以了。不部署高可用通常也不会有太大问题，只要数据不丢失，很快的恢复，没有大的影响。

四、集群部署

Kubernetes理论上可以管理成千上万的节点，但现实总会有不小的差距。有测试显示Kubernetes集群节点数超过500就会出现超时，增加Kube Master节点并不能真的解决问题，所以每个Kubernetes集群节点数有一定的限制，在达到500左右时就需要考虑优化措施，或者按业务条线分集群部署。

通常我们这样的传统企业，节点数也不会很快达到500以上，单一集群一定时间内也可以满足需求。随着节点数的增加，Kube Master节点数也需要增加。其实*初我们考虑只要Kubernetes能保证在Master节点宕机时不影响到业务应用的正常运行，Kubernetes集群的管理工作我们可以忍受一段时间的中断，所以我们没考虑Master节点高可用，但节点数的增加可能必须部署Master节点的高可用，否则可能无法支持kubectl的正常操作。随着节点数的增加master节点数也需要增加。但master节点数超过10就也会带来一些问题，所以通常master节点数是3、5或7比较合适，支持几百个节点。

所以初始情况下，可以用简单的方式，化繁为简，化大为小，采用按业务条线多集群部署方式。这样每个集群确保不会有超过500以上的节点。超过的话考虑新建集群进行拆分。但有些情况下可能需要很大的集群，这个目前采用Mesos可能是更好的方案，从《scaling kubernetes to 2500 nodes》一文中我们了解到Kubernetes可能需要采取不少的优化措施。我们还远未达到这样的集群数量，也没有条件进行测试，所以目前还不能确切知道是否可行。也不知道是否有什么潜在的问题，厂商似乎在这方面也没有太多经验。所以如果可能的话，把大集群拆分为多个小集群，按业务条线、或者按区域等划分，应该是一个可行的方案。

五、控制节点

控制节点就是我们说的master节点，是集群中的大脑和中枢神经，控制和指挥着整个集群的运转。控制节点不可用，整个集群就会陷入瘫痪。*初我们考虑，是否有必要占用那么多的资源来部署控制节点高可用，对我们来说我们可以忍受一段时间内控制节点不可用，只要能及时恢复。部署并不是每时每刻发生，只要部署的业务服务能正常运行，业务不受影响，控制节点暂时的不可用是不会有太大的影响。所以*初我们只考虑部署一个控制节点，不考虑高可用部署。这也是基于我们ESB运维的经验。ESB的控制监控节点故障，不影响业务服务，所以我们有充足的时间来调试恢复ESB控制监控节点。不过Kubernetes跟ESB不同的是，随着节点数的增加，可能需要部署更多控制节点，实现控制节点高可用部署。

Kubernetes控制节点有多个组件，包括kube-apiserver、kube-controller、kube-scheduler和etcd等，这些组件是分开部署还是一个节点上部署？随着集群节点数的增加，可能也是一个不得不考虑的问题。Etcd应该需要单独部署，不同的场景选择合适的磁盘，以及是否使用不同的etcd集群，比如配置中心如果使用etcd，是否和平台合用同一个etcd还是新建一个，需要根据具体节点数量等情况来确定。从《scaling kubernetes to 2500 nodes》文中我们知道，etcd使用了串行 I/O，导致 I/O 之间的延迟叠加，在节点数超过500的时候延迟就增加很多，导致Kubectl操作超时，所以etcd在改用本地SSD磁盘后，etcd终于正常了。另外Kubernetes Events 也可以存储在一个单独的 etcd 集群里，这样对 Events 的操作就不会影响到主 etcd 集群的正常工作。但这也带来了更多的资源投入，以及管理的复杂度。

六、基础组件部署

我们讨论过多次，要建设容器云平台，仅有Kubernetes是远远不够，还需要很多的基础组件来支撑整个业务应用。比如日志、监控、配置、注册发现、服务网关等组件。这些组件是容器化部署好还是虚拟机/物理机上部署好，都是绕不开的问题。

初始节点数量和服务数量少的情况下，可能基础组件容器化部署是个不错的选择。其实就像我们所说的开发测试环境，目的是为了快、敏捷，所以量不会很大。随着节点数增加，服务量增加，不只是Kubernetes自身组件会遇到瓶颈，服务治理服务管理等平台基础组件也会遇到同样的问题。

七、中间件部署

我们建设容器云，很重要的原因是希望利用云上中间件的能力。如果没有中间件服务，那将需要很多的工作来构建这些服务，不过幸运的是，已经有很多中间件可以在容器云上部署。不过同样面临一个“量”的问题，量大的情况下，是否能支撑，是否比非容器化需要成倍的资源来支撑，是否给运维带来一些困难。比如某证券的Kafka集群有20多台，内存配置一般选择64G，采用SSD硬盘，并做了raid5冗余，这样的配置在容器云平台肯定是不合适的，所以需要部署于虚拟机或者物理机上。

在开发测试环境我们还是建议使用容器化环境。在生产根据实际的情况和业务场景选择合适的部署方式。数据库什么的可能就不是很合适，虽然也支持，可以部署，但从运维、安全、组件稳定性等方面考虑，非容器化部署可能更合适。

八、微服务/业务服务部署

微服务肯定是要部署到容器上。目的就是为了利用容器的轻量、隔离、标准化、弹性伸缩等特性。微服务/业务服务往往是需要不断的改进、更新，所以服务整个生命周期要足够敏捷，不只是开发敏捷。其实从这点我们也可以看到，容器化部署比较适合经常变化的、轻量的，那些笨重的、基本没有太大变化的组件如果容器化部署可能无法展现容器的优点。把容器当虚拟机用，有点画蛇添足。其实很多公司选择互联网应用场景部署于容器云作为采用实施容器云的开端，也是因为这些原因吧。看来是英雄所见略同。

我们还讨论过容器化部署时，每个镜像可能会不小，几百兆、甚至上G，跟我们传统ESB服务部署对资源需求就有很大不同。容器化隔离更好，但是每个容器都会重复占用资源。比如Java应用，通常一台机器安装一个JDK就可以了，可以运行很多个Java应用。但对于容器来说，每个容器都需要一个JDK，所以每个镜像都需要打包JDK，在网络传输、存储、运行时资源占用，似乎都没有节约。

公司AppleID的申请详细流程

2021年4月21日
公司AppleID，ID申请
公司AppleID的申请详细流程已关闭评论

申请公司AppleID没有他们所说的那么难！

申请公司AppleId前的准备：公司营业执照，邓白氏编码(没有可以在下边步骤3)

1.首先还是要去苹果官网公司AppleId申请入口》进入如下界面，直接点击右上角的enroll

%title插图%num
1. 1进入如下界面，点击start

%title插图%num
2.进入登录选择界面，如果有AppleId则登录进行选择entity type，没有则点击注册AppleId》

%title插图%num

因为是公司的AppleID所以建议还是从新注册一个，具体的填写内容呢？就像申请QQ那么按照上边的步骤来就行了。值得提醒的是：

1：fistname是名，lastname是姓，并用拼音(不能用汉字哦，当然是可以的但是在后边苹果打电话来验证时会通不过)
2：三个验证问题*好自己用笔记下来，千万不要忘记答案了。

2.1 用AppleId登录后，选择entity type为公司类型
界面如下：

%title插图%num

3.到了这里，就涉及到公司邓白氏编码的事情了
如果公司在这之前还没有申请过邓白氏编码，不要方，按照这里的流程来申请就对了。点击黄色方框中的check now 链接查询公司邓白氏标码进入如下图：

%title插图%num

输入完信息查询后肯定没有D-U-N-S Number的，将刚才填写的公司信息提交就OK？
3.1.刚才提交的公司信息既是在申请公司邓白氏编码。
申请公司邓白氏标码填写信息的时候需要注意，公司的一切信息都得用因为填写。公司的具体地址一定要用英文翻译填写，
我英文翻译能力不行翻译出来的很难看，不过就按照翻译填上去就行。如果不确定翻译是否正确等华夏那边回你邮件的时候委婉的叫他们帮忙翻译一下就OK！提交后会有个确认信息，赶紧的截图保留。
3.2.差不多晚上几个小时就收到了订单邮件：内容如下Thank you for submitting your D-U-N-S Number request / update to D&B. It should be completed by xx/xx/xxxx, or sooner.Your request id is: 102122-353xxx. A D&B representative may be contacting you directly. Your cooperation will help to expedite the resolution of this request.Please contact applecs@dnb.com if you have any questions. 这个号码可不是邓白氏编码。这只是订单编码。
3.3 然后第二天有个上海的电话会打过来确认你如实说就OK了，然后她会说给你发个邮件你如实填写并回复他。内容呢就是公司的一些相关信息。不出意外稍后就能收到邮件(我是晚上11点收到的)，Your D-U-N-S Number request/update submitted on 10/12/2016with ID Number 102122-353336 has been completed. You may start using your number in 14 days.D-U-N-S Number:xxxxxxxxx Resolution Description:
这样邓白氏编码就搞到手了。邓白氏编码是九位数的如邮件内容所说，拿到邓白氏编码需要等14天后才能使用。

4.过了14天，回到第五步，按要求填写公司信息，记得填写的信息比如地址、邮箱、号码、等要和之前写的保持一致，这就是截图或者笔记的好处。填写好信息后继续：

%title插图%num
填写的信息一定要和之前匹对，公司网址如果没有的话可以写一个公司之后会用的域名(或打电话给苹果客服咨询)

4.1提交公司信息，等待审核……

……

%title插图%num

5.如果选择等，估计在2~3天，如果你把老板电话或者邮箱填错了，那不知会等到何时。所以*好第二天就打个电话过去催
ps：我就是今天打过去的，没有办法，老板早定好日期26号上线。昨天才打过去问公司网站的问题，昨天才提交信息今天就去催实在不好意思.

5.1 苹果客服妹妹会很有*貌的提示 5分钟后查看邮箱，进行下一步….

5分钟不到收到邮件：

%title插图%num

点击review 去勾选，表示要同意他们的条条款款。
然后继续。。。继续
到了付款界面

%title插图%num

付款这里填信用卡的信息，有visa和万事达可选，然后订单地址随便填一个就行.
对于像我们这儿公司从来没有搞过外币的当然付款时会失败，不过马上银行会打电话来问问是不是本人操作，然后会提示开通外币。再继续支付，成功》……

填写信息激活账号，至此，从申请邓白氏到成功激活维持大概15天的公司AppleId申请圆满结束!

然而,
……..明天要上架，还有好几个bug！！！

备份数据迁移到云端的七种方式

2021年4月21日
数据备份
备份数据迁移到云端的七种方式已关闭评论

人们可能对云备份的方式有一个普遍的认识，即很少有人希望保留昂贵和过时的遗留系统。下面，让我们来看看云端数据备份可以为组织做些什么。
1.确保合规性
如果组织在全球拥有自己的数据中心或云计算设施，就必须遵守当地的数据法。公共云让始终遵守地理数据规则的组织能够在特定地区存储数据，并无需担心数据安全。此外，使用公共云提供的所有必需安全和认证，包括当地政府机构的安全和认证。由于能够创建为联邦，州和地方政府机构设计的独立云端区域，政府机构可以保护有价值的数据，并始终遵守这些法规。
2.打破孤立的工作流程
为什么不需要单独的备份/恢复，灾难恢复，归档和分析系统?巩固云计算中的基础架构可以集中数据管理，并消除单独的传统系统和工作流程。云计算可以更轻松地处理每个端点，服务器和云应用程序的所有数据，这意味着更高的效率，更少的人为错误和开销。此外，所有数据的中央存储库，允许进行简单的电子发现(eDiscovery)和合规监控。
3.更换过时的流程
云原生技术的出现，解决了历史上依赖内部部署解决方案的过时流程。例如，eDiscovery以前是一个繁琐、昂贵和耗时的过程。通过将其移动到云端，组织可以轻松地简化电子发现流程，完成整个流程所需的时间减少了近50%。
4.始终保持更新及可靠性
云计算没有停机时间，并始终访问*新软件。一旦组织的业务转移到云端，他们可以采用自动软件更新和安全修补程序，而不像传统系统必须等待计划更新。此外，与内部部署解决方案不同，使用云计算可以确保可接受的数据保护和可恢复性水平，价格不昂贵，并满足AWS99.99999%的耐用性保证和99.5%的可用性承诺。
5.降低整体拥有成本(TCO)
组织通过合并云备份和灾难恢复来降低资本支出。除了存储效率低以外，传统解决方案通常具有复杂的定价模式。相比之下，云存储可以扩展或缩小规模，以满足用户需求，使供应商能够提供与实际相符的“即付即用”的定价。基于使用的支付模式，降低软件许可成本以及对专用数据恢复基础设施的需求减少，来进一步缩小整体拥有成本。此外，云计算的全球重复数据删除，节省了网络带宽，并提高了千兆位有效备份速度。*终，云计算的弹性和规模可以适应数据变异性，并让组织有能力在需要时缩小储存空间。
6.整体存储节省资金
公共云架构提供较大的存储容量。在此基础上，本地云存储解决方案可实现集中数据管理，无需采用昂贵的内部设施。通过将活跃数据提供到即时恢复，并将不经常访问的数据自动移动到较低成本的冷存储库中，这时，云计算中数据的自动分层就会*大降低整体成本。此外，分层备份架构还让企业能够更轻松地满足恢复时间目标(RTO)和恢复点目标(RPO)的要求。
7.规范可用性，服务水平和成本
将二级存储工作负载转移到云端，通过共同的地理位置共享平台为企业提供全球数据备份，可用性和治理方法。通过在全球基础设施中采用单一管理点，企业还可以更好地预测成本，有效管理数据，实现服务水平合规性和其它流程的一致性。
这些是将备份数据迁移到云端的七种方式，都能够降低组织的总体存储空间和成本，同时也获得了云原生解决方案可提供的独特优势。

数据中心行业的工程师和架构师，面临的主要网络挑战是什么?

2021年4月21日
数据中心行业
数据中心行业的工程师和架构师，面临的主要网络挑战是什么?已关闭评论

网络容量

对于参与提供网络解决方案的各方而言，网络容量是一个重要问题。如今的公司正在处理数据源产生的越来越多的数据。视频内容的扩散是一个重要因素，因为部署的物联网设备数量不断增加，产生的数据也越来越多。企业还需要处理数据的货币化问题。许多新的商业模式并不是围绕产品销售，而是将信息实现货币化和产品化。

因此，对网络容量的需求将继续增长。并且行业专家给出了很多的网络预测。而且，这并不是因为网络工程师们正在寻找更多的投资方式，而是由于人们总是需要找到一种方法来使用可用的连接和通信资源。

大数据和视频等行业趋势不断发展，但总是会有其他事情发生。例如，智能汽车共享和通信或供应链物流采用传感器，以及制造工厂采用的现场或工业控制传感器。在可预见的未来，将不会出现推动网络容量需求的用例。

除了不断变化的容量需求之外，网络还必须扩展以响应不断变化的安全威胁。随着人们越来越依赖数据和在线服务，对停机或表现不佳的网络的容忍度急剧下降。数据复制和保护策略对企业来说至关重要。

许多公司已经发现，通过将其IT基础设施转移到第三方托管数据中心，可以更经济高效地进行扩展，从而提高效率。

可扩展性

幸运的是，对于*终用户来说，随着需求激增，带宽的成本越来越低。企业面临的挑战是如何按需扩展基础设施以保持*于需求，同时*大限度地提高财务效率。例如，在企业办公室中部署IT资产的组织面临与本地环路电信服务相关的成本效率低下的挑战。这需要快速增加规模。

许多公司已经发现，通过将其IT基础设施转移到第三方托管数据中心，可以更经济高效地进行扩展，从而提高效率。尽管对网络容量、可扩展性、冗余和数据复制的需求不断增长，但这些组织可以更好地降低网络运营成本。

对网络供应商来说，选择可以随之扩展的数据中心合作伙伴非常重要。许多公司在锁定环境之前不会考虑扩展，因此会面临巨大的转换成本。Iron Mountain公司的重点是将数据中心客户引入生态系统，在那里他们可以有效地扩展网络和数据中心的容量，以满足超大规模的需求。

云迁移

云迁移是当今许多组织面临的挑战。通过将业务迁移到云端，组织实际上从操作系统级别的工作进行外包，并在第三方提供的虚拟化平台上运行其应用程序。组织必须决定哪些数据、应用程序和业务逻辑在云中运行，哪些不在云中运行。这还包括一个评估安全性、合规性、控制任务的全新范例。

数据迁移和提取是任何云迁移策略中的关键考虑因素。其中包括管理访问和云计算到内部部署数据中心的连接。

许多组织将围绕何时使用公共云与何时使用私有云制定不断发展的战略，在所有情况下，连接混合IT部署的连接至关重要。

安全性

信息安全有三个主要支柱：机密性、完整性、信息可用性。当查看这些内容时，需要考虑与谁合作以及采用什么方法来实现这一点。容量和可扩展性帮助组织实现目标。物理安全可以影响所有这三个方面。

物理安全是许多组织忽略的主题。他们可能在网络安全方面有一个强大的计划，但是物理访问设备也很重要。物理安全的失效会影响数据的机密性、完整性、可用性。

管理物理安全对于一些组织来说是一个很有挑战性的问题。这就是拥有可靠数据中心合作伙伴的关键所在。

组织不仅需要评估和考虑自己的数据保护实践，还需要评估和考虑每个供应商和合作伙伴的数据保护实践。

合规性

隐私是目前大多数合规计划的前沿和核心问题。许多组织都在努力弄清楚新的隐私法律要求如何影响其合规计划和IT战略。围绕GDPR法规创建的例法并不多，但占到企业收入4%的罚款是相当可观的，因此很容易理解为什么企业会为此担心。

人们看到的另一个趋势是更加重视供应链的完整性管理。这意味着企业的供应商需要更加勤勉。组织不仅需要评估和考虑自己的数据保护实践，还需要评估和考虑每个供应商和合作伙伴的数据保护实践。

组织需要他们可以信任的合作伙伴来保存和管理这些数据，以及相应的合同条款。对于某些组织而言，由于从合规性和审计角度审查新供应商所需的勤勉程度，新的供应商可能需要长达12到18个月的时间。因此，一些组织减少了与之合作的供应商数量，从数量更少的公司购买更多服务。

这些只是当今网络工程师和架构师面临的一些问题，但现在是应对此类挑战的*佳时机，因为市场提供了一些解决方案来帮助组织解决问题，而现在是一个充满动态挑战和解决方案的激动人心的时刻。

Web服务器工作原理详解（基础篇）

2021年4月21日
Web服务器
Web服务器工作原理详解（基础篇）已关闭评论

概述：Web服务器概念较为广泛，我们*常说的Web服务器指的是网站服务器，它是建立在Internet之上并且驻留在某种计算机上的程序。Web服务器可以向Web客户端(如浏览器)提供文档或其他服务，只要是遵循HTTP协议而设计的网络应用程序都可以是Web客户端。

Web服务器和HTTP服务器可以说是同一个东西，当然非得细分的话，HTTP服务器是建立在HTTP协议之上的提供文档浏览的服务器，更多的是提供静态的文件。而Web服务器涵盖了HTTP服务器(这一点可以自行百度百科), Web服务器不仅能够存储信息，还能在用户通过Web浏览器提供的信息的基础上运行脚本和程序。
Web服务器约等于 HTTP服务器 + 其他服务

目前所熟知的Web服务器有很多，其*主流的是 Apache, Nginx, IIS
各大Web服务器的实现细节都不同，是为了某种情形而设计开发的。但是它们的基础工作原理是相同的，这也是本次基础篇所讲解的内容。

一、Web服务器工作原理图解
%title插图%num

首先我们暂时不考虑HTTP协议的各种请求方式，我们先跟着**（Web服务器工作原理总体描述01）这张图，将一次Web服务的工作流程过一遍，我们假设以浏览器作为客户端
(1) 用户做出了一个操作，可以是填写网址敲回车，可以是点击链接，可以是点击按键等，接着浏览器获取了该事件。
(2) 浏览器与对端服务程序建立TCP连接。
(3) 浏览器将用户的事件按照HTTP协议格式**打包成一个数据包，其实质就是在待发送缓冲区中的一段有着HTTP协议格式的字节流。
(4) 浏览器确认对端可写，并将该数据包推入Internet，该包经过网络*终递交到对端服务程序。
(5) 服务端程序拿到该数据包后，同样以HTTP协议格式解包，然后解析客户端的意图。
(6) 得知客户端意图后，进行分类处理，或是提供某种文件、或是处理数据。
(7) 将结果装入缓冲区，或是HTML文件、或是一张图片等。
(8) 按照HTTP协议格式将(7)中的数据打包
(9) 服务器确认对端可写，并将该数据包推入Internet，该包经过网络*终递交到客户端。
(10) 浏览器拿到包后，以HTTP协议格式解包，然后解析数据，假设是HTML文件。
(11) 浏览器将HTML文件展示在页面
以上为Web服务器工作基本原理。其实不难发现，这仅仅只是一个简单的网络通信。我们应该深信，作为一个服务器，其根本的工作无非有三个

接收数据 2. 发送数据 3. 数据处理
而Web服务器的本质就是接收数据 ⇒ HTTP解析 ⇒ 逻辑处理 ⇒ HTTP封包 ⇒ 发送数据
高级的服务器无非就是将这三个部分更加细致的设计了。
二、Web服务器之提供静态文件工作原理图解
Web服务器*主要的功能是提供静态的文件。日常的上网浏览大多是网页浏览，少数时候才会有一些数据的提交操作。因此，我们结合上一张图示来重点讲解在GET请求下的Web服务器工作原理。

%title插图%num

其他流程基本不变，着重在于红色与蓝色部分。
(1) 当用户点击一个网页链接或浏览器加载一些资源(css,jpg …)时产生。
(6) 服务程序解包后，确定其为GET请求，并且是对该服务器上的某一资源的请求。首先服务程序会去确认该路径是否存在，再确定该路径的文件是否可以获取。
(7-1) 如果请求的路径有误，或者该资源不能被用户获取，则返回错误提示页面。很多服务器的错误页面只有404，更专业的应该是将错误分类并返回对应的错误代码页面。
(7-2) 如果该路径合法且文件可以被获取，那么服务程序将根据该文件类型进行不同的装载过程，记录其类型作为(8)中HTTP协议中对应的返回类型，并加入响应头。

假设以点击一个页面链接为例，浏览器首先将HTML文件请求过来，再以同样的流程对HTML文件中包含的资源文件路径进行依次请求。

%title插图%num

三、Web服务器之数据提交工作原理图解
仅仅只是网页的浏览并不能满足所有人的需求，客户端与服务器应当是有数据交互的。
即使单方面的资源请求任然是网络的主力军。
我们应该清楚的知道，数据提交对于用户来说有什么作用。
(1) 资源上传 (2) 登陆验证 (3) API接口调用 (4) 远程指令等
数据提交使得用户的操作性有了质的飞跃，它使得HTTP短连接获取静态文件的方式提升到了动态交互的层次上。该性质也催化出各式各样的编程语言、框架。例如PHP，JavaWeb。
如果你留意目前主流的那些大型服务器，你会发现再高级再牛逼的东西实际是也是*基础的东西建造的。那么我们还可以顺便学习一下*古老的动态技术CGI

%title插图%num

其他流程基本不变，着重在于红色与蓝色部分。
(1) 用户提交数据，假设用户点击一个按键提交填好的信息。在(3)中将以POST格式写入，并填入提交至服务端的可执行程序的路径。
(6) 服务端将参数与该CGI绑定，复制进程，用管道传递参数和接收结果
(7) 子进程执行CGI，接收(6)父进程传来的参数，运算完成返回结果。
*后父进程将结果装入静态模板文件，放入缓冲区

四、动态技术
我们得明白，Web服务器是以短连接为主，并且获取的数据到达浏览器的那一刻一定是静态的不变的。那么所谓动态实际是指两种情况

服务端产生：
(1) 用户POST提交数据到某个程序，程序根据该数据作为参数运行，得出结果并装入静态的模板页面中，返回该静态页面。但对于用户来说，同一个页面，做了一个操作后数据不一样了。好了，这就是动态页面。(CGI原理)
(2) PHP的原理是，用户GET请求一个php后缀的文件，服务器先执行该php后缀文件中的PHP代码，将结果填入代码的位置，再返回。当然也可以提交数据参与运算再返回。
客户端产生：
(1) 用户GET请求一个JavaScript文件，服务端不做任何运算返回该静态文件。浏览器收到该JS文件，在本地执行并更新页面。
(2) 用户POST提交数据到服务端，服务端根据该提交的数据指令返回静态文件，浏览器收到后执行并更新。

Ubuntu搭建DNS服务器

2021年4月21日
DNS服务器, Ubuntu
Ubuntu搭建DNS服务器已关闭评论

前言

其实在我们没有安装DNS服务之前，可以将/etc/hosts文件比作一个DNS服务配置文件，因为它实现和DNS类似。

之所以会独立出DNS服务，是因为因特网主机多，如果每个主机都靠/etc/hosts文件来维护主机名到ip的映射，那么工作量非常大，对本地更新、网络资源占用都很浪费，所以出现了DNS。

私有云的构建组成

2021年4月21日
私有云的构建组成
私有云的构建组成已关闭评论

无论在公有云还是私有云中，你都无需去考虑底层基础设施，而只需要通过虚拟机和网络处理业务。当然，硬件在供应商那里。如果你正在构建一个私有云，会有很多选项来决定如何去构建它。每个选项都有不同的特性、安全性能和成本，但是在任何一种情况下，你都必须保留大量的安全责任。

私有云

这些选项与传统的服务器部署模式类似：你可以部署在自己的服务器上，也可以在一个联合本地中心部署，你甚至可以在“托管但是专用”的基础上使用一个传统的托管服务。

这些指南适用于混合云及私有云。事实上，大多数组织都无法将完全私有的云适当化，但是他们可以为混合模型提供一个很好的案例。在混合云中，你可以通过公有云服务集成一个云并将其运行在由你直接管理的系统上。目前在市场上占据主要地位的公有云——AWS、微软Azure和谷歌云平台——都对这种集成提供了广泛的支持。

有很多的因素会致使你需要在一个私有环境中运行部分或全部系统。通常，依从性、安全性和性能会是主要因素，而且这些因素可能也会对你如何构建、在哪里构建私有云产生影响。

例如，你可能必须将数据保存在某个国家。你也有可能需要安装专业的硬件或使用非传统的配置。也许在公有云中为虚拟机设置的CPU/RAM配置不适合你的需求。也许你有基于GPU的大数据分析系统。你可能还会担心网络延迟。你可以在某些位置通过私有云提供更快的服务，特别是在需要本地处理时。

在自身场地部署，你需要提供一个数据中心，包括电力、电力冗余、HVAC、物理安全、物理网络基础设施和很多的工作人员。对于大多数组织来说，很难去调整。更便宜而且会同样好的方法是只把你的系统和硬件掌握在自己手里，在这个方案中，你拥有计算、存储和网络硬件，并且可以完全控制所有数据，直到它到达传输点。

而联合本地供应商则负责设施、物理安全、消防安全、电力和电力冗余、HVAC和网络连接，以及你能运行专用线路的能力。这些服务减去了很多费用和麻烦，让你能够更专注于自身业务核心。联合本地化的安排可以同时考虑到专业硬件和非正统的配置，它可以很好地改善你的网络性能。

不过联合本地供应商无法阻止你因为某些错误而使你的系统和数据暴露在攻击中，特别是在任何面向网络的情况下。解决办法通常有：确保数据在休眠和传输时是被加密的;保持对身份、身份验证和授权的控制;使用虚拟的下一代防火墙保护面向网络的工作负载;遵循*少特权原则。

托管私有云是另一个使成本下降的方案。上面所描述的那些可能会运行在联合本地设施中的公司，虽然会被承诺硬件是专用化的，但经常会在不明的情况下与他人共享其他资源，有时还会被限制控制选项。你可能不会得到一个单独的网络段或完全管理服务器的能力。在多租户、公有云环境中，肯定存在比你更大的隔离性，但是你需要仔细阅读这些难懂的条文，以确保托管服务满足你的需要，并满足计算主机所需的所有安全职责。

由于各种原因，大型、复杂的组织常常需要维护某些系统的控制。云架构仍然是这些用例的未来，但在这种情况下，它们仍然具有保护数据和软件的义务。

2021 年 4 月
一	二	三	四	五	六	日
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30